[Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?
bjoern.michaelsen at canonical.com
Tue Mar 29 16:51:41 PDT 2011
On Tue, 29 Mar 2011 17:28:26 -0500
Norbert Thiebaud <nthiebaud at gmail.com>
> 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:
> 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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: not available
More information about the LibreOffice