[Libreoffice] Comments on Changes in svtools/source/svhtml/htmlkwd.cxx

[Norbert Thiebaud]

Christina.

commit libs-gui:b247a329c5ca9f8cd1e84fbaca3456be71a87fbf    Removed
lines from merge conflicts

When you run into a hick-up like that (a belated gitt pull -r that
conflicted right ?), and that is _before_ you pushed the offending
commit, it would be nicer to 'amend' the previous commit to fix it
rather than let the unbuildable error and it correction stand.

Right now, I suggest that to make things easier to read (I had to read
the patch because of a bug... see below)
But in the near future, we will be able to use git-bisect in tinderbox
and for it to be effective we must thrive to have the product build at
every commit as much as possible.


Now,

the reason I browse these commits is because I'm seeing:
[ build CXX ] svtools/source/svhtml/htmlout
/lo/tb/svtools/source/svhtml/htmlkywd.cxx: In function 'sal_uInt32
GetHTMLColor(const String&)':
/lo/tb/svtools/source/svhtml/htmlkywd.cxx:1028: error: new declaration
'sal_uInt32 GetHTMLColor(const String&)'
/lo/tb/solver/350/unxlngx6.pro/inc/svtools/htmltokn.h:50: error:
ambiguates old declaration 'sal_uIntPtr GetHTMLColor(const String&)'
make[1]: *** [/lo/tb/solver/350/unxlngx6.pro/workdir/CxxObject/svtools/source/svhtml/htmlkywd.o]
Error 1
make[1]: *** Waiting for unfinished jobs....
dmake:  Error code 2, while making 'all'

that seems to come from essentially from
libs-gui:b8e4fae544147f9af83ec811bac49662481305f4

The thing is that solar.h define:
typedef sal_uIntPtr    sal_uLong; /* Replaces type ULONG */

so substituting sal_uLong with sal_uInt32 is not a neutral
replacement. on 64 bits machine that actually change things.

Now, I'm not arguing that in that particular case sal_uIntPtr make
more sens (I do think that sal_uInt32 is saner here), but sadly the
change has apparently deeper consequences that need to be ironed out.

Norbert