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

[Norbert Thiebaud]

On Tue, Mar 29, 2011 at 3:05 PM, Bjoern Michaelsen
<bjoern.michaelsen at canonical.com> wrote:
> Hi Lubos,
>
> On Tue, 29 Mar 2011 15:11:44 +0200
> Lubos Lunak <l.lunak at suse.cz> wrote:
>
>>  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.
>

I don't think you can do that, sal_* types are rightfully used for
on-disk structure.
you cannot change the size of these type between 2 platform, or you
could not open a file saved on one platform in another.

I think using sal_* judiciously for object that cross the 'external'
frontier is useful.
not so much because of the guaranteed size (intNN_t uintNN_t does that
very well) but because it could
be used to attract the attention to the fact that that
variable/meber/parameter is somehow 'externalized' either via ABI or
serialization.

Using sal_Int32 (or for that mater sal_Int16) in for() loop is not
useful and even conter productive.
forcing the compiler to generate non-optimal code for no good reason.

>
> 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
please note the class of different type described in this link.
it boils down -- for  the most part -- to "stdint.h was not in the
standard yet so we needed to
define type with fixed size to deal with cross platform exchange..."

> http://doc.qt.nokia.com/4.7-snapshot/datastreamformat.html
please not that this last one is 'datastream' i.e serialization.
indeed when you serialize something you can't have compiler dependent
behavior.
quote:"It is always best to cast integers to a Qt integer type, such
as qint16 or quint32, when reading and writing. This ensures that you
always know exactly what size integers you are reading and writing, no
matter what the underlying platform and architecture the application
happens to be running on."

>
> 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, [...]
I would not consider using the C99 standard as 'creatively selected
from other source'

>
>
> 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 do agree with you on the long problem. which boils down to LLP64 vs
LP64 data model
i.e once again essentially Microsoft vs the rest of the world.
http://en.wikipedia.org/wiki/64-bit#64-bit_data_models

But that argument fall flat when one realized that we have code like

typedef sal_uIntPtr    sal_uLong; /* Replaces type ULONG */
...
THAT is confusing and unexpected and already borked with regard to
your valid objection above.

To summarize my view on the matter:

* sal_* type are useful and need to be strictly preserved when dealing
with ABI and/or data-serialization
* sal_Long sal_uLong are evil and confusing and inherently
non-portable. using sal- prefix here gives a false sens of security
* for internal code, especially intra-function local variable 'int'
should be favored when '32 bits is enough'. no platform we support (or
will support, unless someone want to backport libo to Apple II or
something :-) ) has an int that is less than 32 bits long.
* for other case, where one care of one reason or another about the
exact size, then int8_t, uint8_t, int16_t, uint16_t, int32_t,
uint32_t, int64_t, uint64_t are standardized type that do the job just
fine.

None of the above should be construed as meaning that I advocate a
'type conversion campaign'. except for the specific case of sal_uLong,
which _is_ borked already, I don't thing that the benefit/pain ratio
is big enough to justify such a big effort... not to mention the merge
conflicts... Just like agreeing that trailing spaces are a Bad
Thing(tm) does not mean that we are rushing to run clean-up scripts...

And finally, sal_uLong is a problem that need to be resolved. But for
the rest, I just expressed my personal preference. I certainly won't
make that a recurring sticking issue. If we decide stick with sal_*
everywhere, I won't be _that_ upset about it :-)

Norbert