🚀 go-pugleaf

In article <19920826.124331.137@almaden.ibm.com> dmm@vnet.ibm.com (dave) writes:
>In <1992Aug26.184220.8236@taumet.com> Steve Clamage writes:
[In prototyping functions that are defined without prototypes]
>> If enums are smaller than ints, avoid those too.
>
>That means that given
>  enum c { red, green, blue };
>  int f( x ) enum c x; { }
>there is no strictly-conforming way to write a parameter-list prototype
>for the function f.

True.  If you want to use enums but omit prototypes in function definitions,
and if you want to remain portable, then you have to omit prototypes when
calling those functions as well.

However, if you are willing to define your functions as taking ints instead
of enums, then (usually) you can add prototypes in whichever portions of your
program that you wish, and not have to change any of the actual calls, and
maintain portability.  The reason is that the values of enum constants still
have to fit in ints, i.e. portable programs could never have defined anything
like  enum c { red = 32768 };  in the first place.

>  int f( int );
>would be right if  enum c  were of short or char size.  If  enum c  were
>of int or long size, then
>  int f( enum c );
>would be the prototype, right?

Well, if  enum c  were of int size then  int f(int);  would still have been
good enough too.  You get in trouble with long though as you said -- and
possibly also if the standard's citations of "implementation-defined"
integral types are allowed to include implementation-provided extensions to
the standard integral types (an unsolved question).
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
wq