Hi Norbert, On Tue, 29 Mar 2011 17:28:26 -0500 Norbert Thiebaud <nthiebaud@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
Attachment:
signature.asc
Description: PGP signature