>> Whoever fixes this, I'd recommend looking over _all_ the shorts in
>> mail and converting those that don't really need to be shorts to
>> ints.

> Uhm... Since when have ints been guaranteed to be larger then 16
> bits?

Since we started using gcc.  Since we have a kernel that even on a CISC
machine is bigger than a 16-bit address space can encompass.

ANSI C has to cater to elevator controllers running on 8-bit micros.
NetBSD doesn't.  Unless you _are_ writing for toasters or elevator
controllers (in which case you're probably not actually using C but
rather a mostly-C-like language tuned for your processor) I have no
hesitation in recommending that you code assuming ints are at least 32
bits.  _I_ certainly have no hesitation about doing so.

On a more practical note, changing them to ints will fix the problem
for us, and for bitty boxes with 16-bit ints, while it won't fix it, it
will not make it any worse.  When was the last time you saw Berkeley
mail running on a system with less-than-32-bit ints?  On my NetBSD/sun3
machine, /usr/bin/mail is 73728 bytes.  Stripped.  Text alone is 65536
bytes - that doesn't leave room for the shim at address zero, even
assuming a 16-bit machine with code as compact as the 68k's.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B