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

[Bjoern Michaelsen]

Hi Norbert,

On Tue, 29 Mar 2011 17:28:26 -0500
Norbert Thiebaud <nthiebaud at gmail.com>
wrote:

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

Well, lets not forget sal_uLong was born to die:
http://www.mail-archive.com/dev@openoffice.org/msg15185.html
 
> 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

There is no sal_Long. You are right about the sal_ prefix for sal_uLong
though. Esp. for a type defined in tools/solar.h. Maybe we should rename
that one to tools_uLongBrokenType? As you see in the mail above, that
type really _should_ look scary (given the history of types that should
be long be dead in the project by now and really arent at all).

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

I still have some fear in me from all the places in sw and elsewhere,
where I saw stuff like 0xFFFF and intended use of integer overflow. But
maybe thats just paranoia.

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

Maybe we should use those even in sal/types.h by now?
 
> 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 :-)

Understood. We mostly agree here as I see sal_uLong not as a sal-type
(not from sal/types.h).

Best Regards,

Bjoern

-- 
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/20110330/4a4cf632/attachment.pgp>