>Because one of NetBSD's goals is to be portable, and that must include
>64-bit processors.  There is already an alpha port underway, for
>instance.  The only way to make code compile for both 32 and 64-bit
>processors is to use longs wherever you need to cast a pointer to an
>integer, and integers wherever you need something you know is 32-bits.

Unless you're in the kernel, you don't need to cast a pointer to an integer of
any type.  I have never seen a sane counterexample.  Assumnig that an integral
type can hold a pointer is an unwarranted chumminess with the implementation.
The kernel should not be using int or long, it should probably have an i_ptr_t
which is the integral type that can hold a pointer.

If we did this "right", the alpha port would be that much easier -
unfortunately, there's a lot of legacy code that would need careful
conversions, based on knowing whether a long was long to be 32 bits, long to
hold a pointer, or long to be the largest size available.

>There are already a number of people using the NetBSD-alpha port, even
>though its still at a relatively early stage.  However, in the long
>run, the ability to run on new, fast, 64-bit processors will really
>help NetBSD's acceptance.

Yes, and the best way to do it is to agree with DEC that long, being the
largest integral type in C, is the 64-bit type.  Until C9X has
something better to offer.

I mostly object to introducing a new type, not otherwise available in C, when
there are enough existing types to go around.

-s