Hi Norbert, On Tue, 29 Mar 2011 17:28:26 -0500 Norbert Thiebaud <nthieb...@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
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
