consistency in declaration

[david.f.prosser]

In article <14544 at watdragon.waterloo.edu> jyegiguere at lion.waterloo.edu (Eric Giguere) writes:
>In article <13732 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>>In article <64 at BLEKUL11.BITNET> SAAAA04 at BLEKUL11.BITNET writes:
>>>[compiler refuses to accept a prototype with half-named args:]
>>>	void foo(int , int y);
>>>Do I have to be consistent ? Or is this a bug in the compiler ?
>>
>>The pANS grammar allows this notation, and I can't find any constraint against
>>it.  I'd say it's a compiler bug.
>
>Compiler bug?  The specific phrasing in the pANS is
>
>    "A parameter type list specifies the types of, and may declare
>     identifiers for, the parameters of the function." (3.5.4.3)
>
>As Karl says, this does not in fact disallow the case above.  Nor does it
>allow it... it's ambiguous.  Personally I prefer the approach that a
>prototype either declares identifiers for all the parameters or leaves them
>all out.  I really can't see any reason for the inconsistent notation.

The wording in the pANS is not ambiguous in this case.  What it doesn't
directly state is that the parameters in a declaration may or may not be
independently present.  There are a lot of places like this in the pANS.
Since there is a statement that the identifiers must be present in a
definition:

	"If the declarator [in a function definition] includes a parameter
	type list, the declaration of each parameter shall include an
	identifier (except for the special case of a parameter list
	consisting of a single parameter of type void, in which shall not
	be an identifier)."  [section 3.7.1]

I believe this a clearly a case of the pANS requiring that conforming ANSI
C compilers accept both named and unnamed parameter declarations in a non-
definition prototype.

>
>In any case that's the way we've implemented it in Waterloo C.  Apparently
>that's the way Microsoft does it as well... Watcom C probably does it that
>way too.... but I suppose we're quibbling over very minor details.

By my reading, then these compilers are not going to be ANSI C conforming
by the time that the pANS losses its "p", not that this is an important
feature in anybody's book.

On the other hand, if it were also allowed in a definition context, then it
*would* be a minor, but important, feature to me.

> 
>Eric Giguere                                  268 Phillip St #CL-46
>For the curious: it's French ("jee-gair")     Waterloo, Ontario  N2L 6G9
>Bitnet  : GIGUERE at WATCSG                   (519) 746-6565
>Internet: giguere at aries5.UWaterloo.ca         "Nothing but urges from HELL!!"

Dave Prosser	...not an official X3J11 answer....