Created attachment 13268 [details]
Patch for tools

Created attachment 13269 [details]
patch for sal

Created attachment 13270 [details]
unzip into sal/, so that a sal/typesconfig exists

To get this to work:

1) apply patch to tools
2) delete tools/source/solar directory
3) apply patch to sal
4) unzip typesconfig.tar.gz in sal, so that a sal/typesconfig directory exists

Looking at sal.diff, I have a number of questions:
1  What is the _SOLAR_NODESCRIPTION define good for?  Also, it is an illegal
macro name (it starts with an underline followed by an uppercase letter), and
the notion of "solar" does not fit with the notion of "sal," I think.
2  Please replace the lines

  #else  /* UNX */
  #if defined WNT /* auf PC's */

with the single line

  #elsif defined WNT

which is much more readable.
3  All the macro names from __LITTLEENDIAN to __IEEEDOUBLE are illegal (they
contain a double underscore).
4  Macros for little vs. big endian are already available in osl/endian.h.
5  __SIZEOFCHAR is of no use, as sizeof (char) must always equal one, anyway.
6  The codified assumption that "sizeof (long) != 4" implies that [unsinged] int
has enough non-padding bits to represent all the values we expect to store in an
object of type sal_[u]Int32 is false.

I had naively thought that the generated sal/typesizes.h would be available on
all platforms, and would already contain the relevant typedefs and macros
(sal_[u]Int8/16/32/64 and SAL_CONST_[U]INT64), instead of this two-stage process
(which, on the one hand, would be applied inconsistently, as the information
from sal/typesizes.h is only used to determine the typedef of sal_[u]Int32, and
not for sal_[u]Int8/16/64, and, on the other hand, is generally dangerous, as
the sizes (as per sizeof) of integer types alone are not sufficient to determine
what integer types, if any, are the best candidates for our sal_[u]Int8/16/32/64).

1) _SOLAR_NODESCRIPTION is directly from tools/solar.h, and I was concerned enough about it to 
include it here since there are things that could break if it wasn't.  What those are, I don't know, and it 
may be a completely historical artefact.

2) Will do.

3) Will change macro names

4) Does this work on Windows?  Will the test program ever work on Windows?  If it would, then we 
should not use osl/endian.h and instead generate such things with the test program.

5) Will remove SIZEOFCHAR

6) Explain a bit more what you mean here.

If its not as much as you hoped it would be, then lets make it so.  This is still very useful on Unix-based 
OSs, even _between_ versions of Unix-based OSs, to determine things like 64-bitness and other 
problems with assumptions that we might make (long being 32-bits for example).

Also, why should it autodetect sal_[u]Int8 when you state we are assuming that char is always 8-bit?  I 
think the solution here is to define based on the macros for 16/32/64 bit types.  There's also AFAIK no 
good way to determine "SAL_CONST_[U]INT64" either, suggestions welcome.

Created attachment 13296 [details]
updated patch

Created attachment 13297 [details]
updated patch

Created attachment 13298 [details]
updated typesconfig program

Changes include:
1) removal of stack stuff from typesconfig program, some parts were used (stack direction) and other 
parts (stack alignment) were only used on Classic Mac OS
2) removal of typesizing for "char" types, since Stephan said we should always assume 8-bits
3) check sizes for 16, 32, and 64-bit types in sal/typesizes.h
4) clean up 64-bit type defines in tools/solar.h
5) spacing improvements

Created attachment 13301 [details]
Updated tools/ patch, use instead of tools.20040219.patch

Due to Stephan's request for renaming the __ defines, there will be many more modules to be touched.  
I vote that we do not attempt to fix all the __LITTLEENDIAN and __BIGENDIAN defines right now (as 
there are a lot) but instead temporarily define then to be their SAL_TYPES_xxx counterparts.

Created attachment 13305 [details]
patches for modules switching to SAL_TYPES_*, except for __LITTLEENDIAN and __BIGENDIAN

reassign to fa, as Dan takes care of this.

We are less flexible with the contents of sal than with the contents of tools
(since sal is part of the published SDK API; whatever we add to sal has to be
maintained "forever"), so I would like to propose to reduce the number of macros
added to sal a little:

-  Use the already existing OSL_LIT/BIGENDIAN from osl/endian.h, instead of
defining new SAL_TYPES_LITTLE/BIGENDIAN in sal/typesizes.h or sal/types.h.

-  At least on platforms with 8-bit bytes and no padding in arithmetic types
(see below), supporting IEC 60559 (aka IEEE 754) implies that sizeof (double) ==
8, so that SAL_TYPES_SIZEOFDOUBLE can be removed.

-  Support for IEC 60559 (aka IEEE 754) is an assumption that cannot be lifted
anyway (see below), so I'd vote to drop SAL_TYPES_IEEEDOUBLE.

Our code is based on some assumptions about a platform.  There are probably too
many places in the code that rely on these assumptions (and these assumptions
are probably met by all current hardware, anyway), to make it realistic to get
rid of these assumptions.  Among these assumptions are:
-  A byte has eight bits.
-  Arithmetic types have no padding bits.
-  Signed integral types use two's complement.
-  Floating point types use IEC 60559.

committed to cws_src680_ooo64bit01 with sba's suggestions

Verified, closing.