> 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.

I think this is a perfectly reasonable thing to do.  However, until
there is a standard that tells us what to do, I don't see any point in
doing this:

> 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.

The ANSI standard doesn't tell us how many bits are in a long, or in
an int, or how to express a 64-bit quantity.   It is permissible for
an int to be 16 bits, 32 bits, or, as on the Alpha, 64 bits.   It is
permissible for sizeof (long) to be less than sizeof (int), and this
is an approach that has been used by several vendors to deal with this
problem.

I don't see any point in solving this problem in advance of a
standard.  The NetBSD team is a bunch of hackers, not a standards
body.   And since setting a de-facto standard here, at least the one
you propose, would break a lot of third-party code, I don't see any
point in doing it.

			       _MelloN_