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

On Wednesday 30 of March 2011, Bjoern Michaelsen wrote:
> Lubos Lunak <l.lunak@suse.cz> wrote:
> >  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
> > int.
>
> Some sal_* => "int" conversion that works on all current platforms does
> not have to on the next one coming around.

 Of course it does. Either you want marshalling that works everywhere, in 
which case types with given size should be used, and then it's better to be 
explicit about them, or you just want it to work in that specific place (one 
setup) and then it's just the same type, whatever it is. What other option is 
there?

> >  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

 I think we both have, albeit for different reasons, agreed that nobody really 
wants to use 'unsigned int'. I can give you the numbers for sal_uInt64 too if 
you want a "proof" that there's only minor usage of sal_ types. Grep 
for '\bint\b' or '\blong\b' if you want to see that standard types usage is 
significant.

> >  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.

 If the conclusion is that the easy task is not worth the merging problems, 
that's still in line with my claim that the easy task is wrong as it is. It 
just needs removing completely in that case.

-- 
 Lubos Lunak
 l.lunak@suse.cz