Subject: Re: rpcgen and -fshort-enums round 2
To: NetBSD Toolchain Technical Discussion List <tech-toolchain@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
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)?
> 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
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; <email@example.com>; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>