Subject: Re: rpcgen and -fshort-enums round 2
To: NetBSD Toolchain Technical Discussion List <tech-toolchain@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-toolchain
Date: 02/19/2002 19:28:01
[ 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;  <>;  <>;  <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>