> The real question is, is this a direction we want to go in?  If so, we
> start using int64_t for long long, int32_t for long, int32_t for int,
> and int16_t for short.  Then, when none of our code cares which is which,
> we make the subtle change, and change one (1) header.  Then we start
> fighting 3rd party code.

Again i will point out: DOING SOMETHING LIKE THIS IS VERY STUPID.

why?

because of performance.  one can't say how "use of a 32-bit integer"
will perform on a given system.  what about on a Cray?


'int' should be the natural word size of the machine. (yes, on the
Alpha, it arguably should be 64 bits, but the alpha provides
operations that load, store, and operate on 32-bit quantities, and
32-bit ints were just too much to give up.)

'long' should be an integral type greater or equal in size to 'int',
and short should be an integral type smaller or equal in size to
'int.'


if you're going to insist that 'long' be the largest integral type,
then the way to get larger types, e.g. quads, on machines where 'long'
is 32 bits is to use a struct or array of smaller types.  the answer
IS NOT to fix the size of 'int', 'short' and 'long' on all systems
and increase 'long' to 64 bits, or use explicitly-named fixed-size
types all over the system, where they're otherwise unnecessary.



cgd