Subject: Re: rpcgen and -fshort-enums round 2
To: None <tech-toolchain@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-toolchain
Date: 02/19/2002 16:12:02
[ On Tuesday, February 19, 2002 at 13:28:48 (-0500), der Mouse wrote: ]
> Subject: Re: rpcgen and -fshort-enums round 2
>
> >> Maybe changing all functions that take enum args is easier.
> > If this is true, perhaps using K&C style function definition with
> > __P() macro may be better than current ANSI style function style.
> 
> ...??  As I recall C, a prototype declaration is incompatible with an
> old-style definition (at least if the prototype uses any types that
> change when run through the default promotions),

Yes, in ANSI C a prototype declaration is only incompatible with an
old-style definition if the prototyped function uses any types that
would otherwise be promoted using the old-style parameter promotion
rules.  Of course proper casts must also always be used to force
old-style parameter promotion on every call too, esp. if you allow your
ANSI compiler to succeed when it has no prototype in scope.

> and if you __P() the
> prototype away, you've just got a plain old-style everything.

I'm not sure what you mean there.

In an ideal portable C program you will define and declare your
functions (using __P() or something the same) such that the old-style
parameter promotion rules are explicit and not implied, and then if the
program, or even any part of it, is compiled with an ANSI C compiler
nothing will change regardless of whether the ANSI compiler sees the
prototype declarations or not.

Unfortunately because of the unnecessary changes to the parameter
promotion rules a pure ANSI compiler must see prototypes for all uses of
a function in case the uses of that function do not all explicitly
demand (by way of casts) old-style parameter promotions.

>  In gcc,
> an old-style definition with a previous prototype declaration is
> silently converted to a new-style definition, so you have the same
> incompatability you do with a wholly new-style approach.

Yes, that's right.  The same should happen for any ANSI C compiler.

> > Because gcc can automatically generate warning message against such
> > usage (manual checking is not nice....).
> 
> I must be missing something here.  Can you give an example of how your
> suggestion improves matters?

I don't know if this is what was meant but some folks feel that even if
you explicitly restrict your programming to old-style parameter rules
the benefit of prototype declarations is positive.  However I don't
think it's quite as good as what can be had by using automatically
crafted lint libraries since the latter can check for old-style
portability and many other things too.

<soapbox>
Function prototypes are really just a crutch for lazy programmers (and
no C programmer can ever afford to be lazy, ANSI-C or not!).
Unfortunately function prototypes cause worse problems than they solve
because of the unnecessary changes that were made to the parameter
promotion rules.  You really do not gain back enough safety features by
being able to pack smaller types into int-sized registers or whatever.
</soapbox>

-- 
								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>