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

[Bjoern Michaelsen]

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). 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). All these
points are friction points. And LO is not a small project and will be
ported to new platforms. And the next platform will not be different
that the previous ports, there will always be some trouble.

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

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.

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

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.

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

That is a Strawman: I was talking about numeric types and numeric
types only, which the bool/BOOL/sal_Bool/FASTBOOL madness is completely
different from. Also sal_Bool and bool map perfectly and the same way
on all platforms(*).

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.

Best Regards,

Bjoern


(*) unless viciously abused.
-- 
https://launchpad.net/~bjoern-michaelsen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110329/951b103d/attachment.pgp>