[Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?

Lubos Lunak l.lunak at suse.cz
Tue Mar 29 06:11:44 PDT 2011


On Monday 28 of March 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
> On Mon, 28 Mar 2011 12:45:11 +0200
>
> Lubos Lunak <l.lunak at suse.cz> wrote:
> >  Specifically, the simple and logical type for numbers happens to be
> > 'int'. Some kind of intptr type is usually only for ugly hacks, and
> > bit-precise types are mainly for marshalling. Is there any point in
> > keeping the task as it is or can I change it to 'use sal_uInt32 if
> > the precise size is need, e.g. for marshalling, use sal_uIntPtr if it
> > is used for storing pointer value, otherwise simply use int'? And,
> > looking at this description, is there any plan to get rid of these
> > superfluous sal_xxx types eventually?
>
> IHMO, our aim should be to have _one_ canonical set of numerical types
> in LibreOffice, and not one for marshalling, one for other cases.

 Why not? I generally just need a number and int fits that perfectly. I really 
don't care how many bits it has as long as it works and don't need to wonder 
if I should use sal_Int32, sal_UInt16, sal_Int64 or whatever.

> Using non sal_* numeric types is just asking for trouble in the long
> run, because some day you will need to marshall that stuff somewhere.

 How is that different from having different sal_whatever in the code and 
marshalling with that? If size-specific types are kept only for marshalling, 
then it's at least obvious what the marshalling format is.

> And there is absolutely no hurt in using the sal_* typedefs(*).

 It's more typing and it's foreign to anybody not used to the codebase. Sure, 
that may sound like silly reasons, but it's still two more reasons than I can 
come up with for the other way around. Besides, I have already seen a number 
of commits changing BOOL/sal_Bool to bool, so at least some people seem to 
see the value of abandoning the sal_ types where not necessary.

-- 
 Lubos Lunak
 l.lunak at suse.cz


More information about the LibreOffice mailing list