On Tue, Mar 29, 2011 at 3:05 PM, Bjoern Michaelsen <bjoern.michael...@canonical.com> wrote: > Hi Lubos, > > On Tue, 29 Mar 2011 15:11:44 +0200 > Lubos Lunak <l.lu...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
