🚀 go-pugleaf

In article: <1996Feb23.090526.7591@sq.com>  msb@sq.com (Mark Brader) writes:
> 
> Dan Pop (danpop@mail.cern.ch) writes:
> > Does the following code require a diagnostic?
> > 
> >     foo() { }
> >     main() { foo(3); } > 
> > I was always convinced that there is no difference between foo() and
> > foo(void) in the _definition_ of the function foo ... Yet, all the
> > compilers I tried accepted this code without complaint and complained
> > when 'void' was introduced in the definition of foo.
> 
> The language of the standard is fuzzy here, but I believe that it is
> clearly intended for the diagnostic to be mandatory when the "void" is
> present, and optional otherwise (the behavior being undefined).
> 
> An excerpt from the Constraints of section 6.3.2.2/3.3.2.2 (emphasis added):
> 
> #  If the expression that denotes the called function has a type that
> #  INCLUDES a prototype, the number of arguments shall agree with the
> #  number of parameters.
> 
> As this is a Constraint, a violation requires a diagnostic.  But from the
> Semantics of the same section (emphasis added):
> 
> #  If the expression that denotes the called function has a type that
> #  DOES NOT include a prototype ...  If the number of arguments does
> #  not agree with the number of parameters, the behavior is undefined.
> 
> Thus no diagnostic is required if this is the only violation.  I must
> say it's rather disgusting that none of the compilers Dan tried was smart
> and helpful enough to produce the diagnostic anyway -- it would after
> all be easy enough for them to do so in this case.  (Cancel that remark
> if they were all compilers intended to be used with lint for checking.)
Don't be too unfair to the compiler writers - they're trying to write
compilers that accept K&R C as well as ISO C. You may not think this is a
good idea, but there's vast amounts of legacy code with K&R header 
files out there.... The authors of the standard tried to make it 
compatible with "current practice" (ie K&R) as far as possible: that is 
why the declaration of foo() with no parameters is allowed at all.
> 
> Now, "prototype" is defined in 6.1.2.1/3.1.2.1:
> 
> #  A "function prototype" is a declaration of a function that declares
> #  the types of its parameters.
> 
> And in case there was any doubt, both 6.5/3.5 and 6.7.1/3.7.1 make it
> clear that a definition is a kind of declaration.  I won't bother to
> quote them here.
> 
> 
> These passages are sloppy for the following reasons:
> 
> 1. "Function prototype" is defined, but the term used elsewhere in the
>    standard is just "prototype".
> 
> 2. It is defined as a syntactic construct, not something that might be
>    "included" in a type.
> 
> 3. If a function has no parameters, it is not possible to distinguish
>    whether they are declared or not.
> 
> 4. The old-style function definition
> 
> 	void fu (x,y) short x,y; { }
> 
>    is a declaration that declares the types of the function's parameters,
>    but if this was deemed to be a prototype, existing code would be broken.
> 
>    The way to resolve both points 3 and 4 is to relate the term "prototype"
>    more directly to the new-style syntax, which it is obviously intended
>    to denote.  In section 6.5.4.3/3.5.4.3, where function declarators and
>    their semantics are actually defined, the term is avoided altogether and
>    "parameter type list" is used instead.  "Prototype" probably should have
>    been defined in these terms.  Note that void is a type, so foo(void)
>    would be a valid function declarator with a prototype, while foo()
>    would unambiguously not have a prototype.  There is no syntactic
>    ambiguity since a parameter type list is not allowed to be empty.
> 
> 5. The punctuation of the quoted passage from 6.3.2.2/3.3.2.2 Semantics
>    is ambiguous: it isn't clear whether the first If-clause quoted is
>    meant to govern the second one, which is in a different sentence.
>    More precisely, the punctuation suggests that it does not, but in
>    other places in the standard similarly punctuated, it would.  In
>    this case, however, material later in the paragraph suggests that
>    the last-quoted If-clause is not meant to be within the scope of the
>    other one.
> 
>    Fortunately, this parsing ambiguity makes no difference in this case;
>    the overall effect is the same with either parsing, no matter whether
>    a prototype is used or not.
> 
> If you take the intended readings as being what I said, then you end up
> with the conclusion I gave above.  If not, you probably don't.
> -- 
> Mark Brader, msb@sq.com       "I'm not a lawyer, but I'm pedantic and
> SoftQuad Inc., Toronto         that's just as good."      -- D Gary Grady
> 
> My text in this article is in the public domain.
> 
> 

--
Richard P. Parkins, M. A.     rpp@pires.co.uk
Pi Technology Ltd.            +44 (0)1223 441434
Opinions expressed were mine at the time of posting,
otherwise all possible disclaimers apply.