[ On Wednesday, February 20, 2002 at 00:00:44 (+0000), David Laight wrote: ]
> Subject: Re: rpcgen and -fshort-enums round 2
>
> Can I agree (for once)?

Sure!  ;-)

> I've seen too many function prototypes where, because the DOMAIN of
> an argument is [0..65535] the argument is defined as 'unsigned short'
> (rather than int).  On most modern systems this causes the compiler
> to generate reams of extra code to ensure that 65535+1 => 0.

Indeed and so even if several shorts or chars were packed into one
register to be passed to a function it still takes more cycles than you
can imagine to get them back out and to use them afterwards!

Once upon a time we used to think that using "int" on wide-word machines
would be a terrible waste for ASCII strings, but these days with Unicode
such worries seem quite "antiquated"!  ;-)

> IMHO local variables, parmeters and function results should almost
> always be [unsigned] int - unless you require wrapping at 2^8 or
> 2^16.

Indeed -- there is after all a very good reason why the width of an
"int" was originally defined to "reflect the most ``natural'' size [of
an integer value] for a particular machine."  :-)

I don't even have the time of day for the idiot who first thought that a
char should be passed as a char.  However it would have been nice if DMR
had thought to start us off with a rule that artificially narrowed types
were not legal in parameter definitions in the first place (which in a
sense he did -- he just didn't word it right).  That way maybe the
normal promotion rules wouldn't have been bastardised by ANSI.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>