Potential (small) ABI switch

[Martin Husemann <martin%duskware.de@localhost>]

Folks,

we are currently trying to synchronize the idea the compiler has about
the various int types and the declarations in the NetBSD headers.

This mainly boils down to minor differences in the {u}int_fastN_t definitions.

There is no obvious single wrong or right way for sparc64 (IMHO), and
a few days ago we "accidently" switched ABI for these types by moving from
the old header definitions to new ones based on the compiler defaults.
A few other architectures will soon be fixed by adapting the compiler's
idea about these types to the old NetBSD headers, but I am leaning toward
not following this move with sparc64.

As of netbsd-6 sparc64 used:

int_fast8_t             long int (64 bit)
uint_fast8_t            unsigned char (8 bit)
int_fast16_t            long int (64 bit)
uint_fast16_t           unsigned short int (16 bit)
int_fast32_t            long int (64 bit)
uint_fast32_t           unsigned int (32 bit)
int_fast64_t            long int (64 bit)
uint_fast64_t           unsigned long int (64 bit)

As far as I can tell Solaris always used the same types as without "fast",
e.g. uint_fast8_t = uint8_t, int_fast8_t = int8_t, ...

Everyone else uses a much simpler sheme:

int_fast{8,16,32}_t     int (32 bit)
uint_fast{8,16,32}_t    unsigned int (32 bit)
int_fast64_t            long int (64 bit)
uint_fast64_t           unsigned long int (64 bit)

... and this is what we have now in -current as well. IMHO it can stay this
way. While the old NetBSD state is arguable from the instruction set POV,
it is not a clear winner speed wise and the C standard leaves quite a bit
of rope.

Strictly speaking this is an ABI breakage/change, worse with C++ - and in
general this is something we don't do in NetBSD, so this needs carefull
thoughts.


Martin