[Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?
bjoern.michaelsen at canonical.com
Wed Mar 30 03:56:10 PDT 2011
On Wed, 30 Mar 2011 11:21:26 +0200
Lubos Lunak <l.lunak at suse.cz> wrote:
> How does API have to do anything with marshalling?
> Do you mean UNO with that?
> And what do you estimate is the ratio of code that does marshalling
> to the rest of the code?
In the applications (and that is the major code block) practically
everything, as everything has at least some UNO wrapper -- and UNO is
also used a lot internally.
> If it's used for marshalling, then it can't be changed. Or, if it
> can, then it doesn't matter if the data would be simply marshalled as
Some sal_* => "int" conversion that works on all current platforms does
not have to on the next one coming around.
> Are you sure you're not arguing for my way here? The only way to get
> the same type is if the codebase normally used int. Now it's full of
> different types (sal_* ones and standard ones, all mixed).
I think most code now uses sal_* as of now and less code uses the
standard ones. For example, searching for this stuff roughly a la
find clone -name "*.cxx"|xargs grep "unsigned int"|wc -l
in clone (excluding libs-extern):
sal_uInt32 unsigned int
clone without external 24005 1246
hxx 7560 256
cxx 16445 999
Thus my conclusion.
> And I'm also not arguing for converting everything right now this
> very moment. But I don't see why we should have an easy task that
> moves the situation in the wrong direction.
Agreed. Changing stuff there will just create lots of useless merge
conflicts. And if we see Oracle doing something stupid with sal_uLong,
we should do our better solution after _merging_ that. The worst
situtaton however is: they walk on to greener pastures because
priorities changed this week and sal_uLong keeps hanging around.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: not available
More information about the LibreOffice