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

[Lubos Lunak]

On Tuesday 29 of March 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Tue, 29 Mar 2011 15:11:44 +0200
>
> Lubos Lunak <l.lunak at suse.cz> wrote:
> >  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.
>
> For example you will create a lot of needless work for people who want
> to get the code warning-free (which is a valid goal, see Caolans commits
> for example) because of comparisons between different types
> (signed/unsigned or different ranges).

 I don't think there's any warning for comparing differently sized types of 
the same signedness, as the smaller one is simply promoted to the larger one. 
And, because of the trouble caused by promotion rules when comparing signed 
vs unsigned, it's just not worth using unsigned for anything except bitwise 
operations. In fact insisting on the wide range of different types leads to 
more warnings, not the other way around - if everything that's simply a 
number is int, there are no warnings. I also doubt that using differently 
sized typed rigorously gains anything - types smaller than int are promoted 
to int in pretty much any operation, so presumably no warnings there, and as 
soon as there's an operation that involves two different types, it's probably 
just not worth the trouble.

> Almost every numeric data you 
> have in the codebase has been marshalled once, or will be (it was
> either loaded, will be saved or is available though the API).

 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?

> sal_* Types are typedefs and can be changed as a whole or be defined
> different on different (or new) platforms. That eases a lot of trouble.

 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.

> >  It's more typing and it's foreign to anybody not used to the
> > codebase. Sure, that may sound like silly reasons
>
> Indeed. And its wrong too. As "unsigned int" is for example a lot longer
> to type than sal_*.

 Typing is not really the biggest problem of unsigned int, see above.

> Also its really not something only LO does: 
>
> http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html
> http://doc.qt.nokia.com/4.7-snapshot/datastreamformat.html

 The Qt page is about data marshalling. Normally Qt uses int wherever 
possible.

> Also, you are not making it easier for the newcomers at all: If he gets
> a sal_* type from one source and a creatively selected other type from
> another source, you are making life hard for him. If he gets the same
> types there is no trouble for him.

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

> That is not at all the case for numeric types (for example "long").
> Someone writing code on *nix might easily store a sal_uInt64 in a long
> on 64-Bit and create havoc on Windows in interesting and hard to
> reproduce ways.

 I was talking about the case where the value is "just a number". If it needs 
an extended range for whatever reason then that's something different.

 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.

-- 
 Lubos Lunak
 l.lunak at suse.cz