Re: (part 21) Han from China answers your C questions

[lawrence.jones@siemens.com]

Re: (part 21) Han from China answers your C questions

Tim Rentsch <txr@alumnus.ca ltech.eduwrote:

>
if compilers simply started reporting this as an error
(which certainly seems reasonable, since it is guaranteed
UB if ever executed), then the standard committee might be
convinced to let such function definitions serve as prototypes.

During the C89 deliberations, the committee considered a "Miranda rule"
("You have the right to a prototype. If you cannot afford a prototype,
one will be appointed for you.") that would allow old-style function
definitions to serve as prototypes, but it was reject for fear of
breaking too much old code.
--
Larry Jones

Fortunately, that was our plan from the start. -- Calvin

[Tim Rentsch]

Re: (part 21) Han from China answers your C questions

lawrence.jones@ siemens.com writes:

Tim Rentsch <txr@alumnus.ca ltech.eduwrote:

There is
nothing in the standard that ties the term "prototype" to the
syntactic nonterminal "parameter-type-list".

>
6.2.7p3:
>
-- If only one type is a function type with a parameter type
list (a function prototype) ...
>
6.9.1p7:
>
If the declarator includes a parameter type list, the list also
specifies the types of all the parameters; such a declarator
also serves as a function prototype for later calls to the same
function in the same translation unit.
>
6.11.7:
>
The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

Before my earlier posting I had looked at all of these:

6.2.7p3 looks like a non-restrictive parenthetical remark, not a
definition.

6.9.1p7 says such a declarator /also/ serves as a function prototype;
again, looks more like an additional remark than a definition.

Neither 6.11.6 (which is given above under the numbering 6.11.7) nor
6.11.7 mention the syntactic non-terminal parameter type list.

It's clear that a parameter type list must provide a function
prototype; what isn't clear is that a function prototype requires a
parameter type list. This latter condition is what I meant when I
said "There is nothing in the standard that ties the term 'prototype'
to the syntactic nonterminal 'parameter-type-list'." I believe
that reading of the sentence is still an accurate statement.

To be fair, the comment under "6.11.6 Function Declarators" makes
evident the implication that empty parentheses don't fall under the
heading of prototype. If I'd been a little more alert I would have
realized that this applies to function definitions as well as function
declarations, since function definitions also have function
declarators (but then no one else caught this either). What threw me
off was the apparent dichotomy between 6.11.6 and 6.11.7, seeming to
make separate statements about /declarations/ and /definitions/; for
the sake of clarity, it might be good to combine these two sections
into a single section (titled Function Declarators) with two paragraphs.

[Tim Rentsch]

Re: (part 21) Han from China answers your C questions

lawrence.jones@ siemens.com writes:

Tim Rentsch <txr@alumnus.ca ltech.eduwrote:

if compilers simply started reporting this as an error
(which certainly seems reasonable, since it is guaranteed
UB if ever executed), then the standard committee might be
convinced to let such function definitions serve as prototypes.

>
During the C89 deliberations, the committee considered a "Miranda rule"
("You have the right to a prototype. If you cannot afford a prototype,
one will be appointed for you.") that would allow old-style function
definitions to serve as prototypes, but it was reject for fear of
breaking too much old code.

Perhaps that was the right decision in 1989. For the particular case
of function definitions that take no parameters, for C201x, the
downside seems pretty small -- any code that supplies any arguments to
such a function is still undefined behavior. There is no change in
semantics, only a requirement that a diagnostic be issued, which could
be satisfied by compilers simply giving a (non-negotiable) warning and
then just going ahead with the compilation.

I understand the reasons for requiring (void) so that a zero-parameter
function declaration supply a prototype. But requiring (void) for a
zero-parameter function /definition/ to be a prototype just seems
wrong.

[Keith Thompson]

Re: (part 21) Han from China answers your C questions

Tim Rentsch <txr@alumnus.ca ltech.eduwrites :
[...]

I understand the reasons for requiring (void) so that a zero-parameter
function declaration supply a prototype. But requiring (void) for a
zero-parameter function /definition/ to be a prototype just seems
wrong.

To me, it seems more wrong to be inconsistent.

C++ took a different route, eliminating non-prototype function
declarations altogether and making () a prototype specifying no
parameters. It would have been nice if C had done the same thing, but
it would have broken backward compatibility.

Non-prototype function declarations are already deprecated in C; see
C99 6.11.6 and 6.11.7. The next standard *could* just eliminate them
altogether and make "void foo(void)" and "void foo()" equivalent
prototypes.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones@siemens.com]

Re: (part 21) Han from China answers your C questions

Tim Rentsch <txr@alumnus.ca ltech.eduwrote:

>
It's clear that a parameter type list must provide a function
prototype; what isn't clear is that a function prototype requires a
parameter type list.

That's because you've been missing the fact that the *only* way to
specify the types of the parameters in a function declaration is by
using a parameter type list. The references I cited, while not
definitional, clearly make that connection.

What threw me
off was the apparent dichotomy between 6.11.6 and 6.11.7, seeming to
make separate statements about /declarations/ and /definitions/; for
the sake of clarity, it might be good to combine these two sections
into a single section (titled Function Declarators) with two paragraphs.

Noted.
--
Larry Jones

But Mom, frogs are our FRIENDS! -- Calvin

[Tim Rentsch]

Re: (part 21) Han from China answers your C questions

lawrence.jones@ siemens.com writes:

Tim Rentsch <txr@alumnus.ca ltech.eduwrote:

It's clear that a parameter type list must provide a function
prototype; what isn't clear is that a function prototype requires a
parameter type list.

>
That's because you've been missing the fact that the *only* way to
specify the types of the parameters in a function declaration is by
using a parameter type list. The references I cited, while not
definitional, clearly make that connection.

Apparently my attempt to clarify the meaning of my earlier statement
was unsuccessful. I will try again.

None of the cited references make a direct, explicit statement that
using parameter type lists are the only way to specify the types of a
function's parameters. One makes no reference to parameter type lists
at all; the other two establish that declarations with a parameter
type list serve to provide a prototype (and also supply the types of
the parameters, obviously), but do not say that parameter type lists
are the /only/ way to specify the types of a function's parameters (or
to provide a prototype).

The lack of the word "only" is important, because if there are other
types of declarations that specify a function's parameter types, then
they also provide prototypes. For example, if 6.7.5.3p14 establishes
(as it seems to on first reading) that a function definition with no
parameters specificies a function type with no parameters, then it
also specifies the types of the function's parameters. It turns out
that 6.7.5.3p14 does not establish the number of parameters in the
function's type, but it does seem like it might, and the lack of the
word "only" in other statements about parameter type lists adds
signicantly to the lack of certainty.

I agree that, taking several different sections of the standard and
considering them together, a pretty convincing argument can be made
that only parameter type lists specify the types of function
declaration parameters; however, this result is a consequence of
statements made in fairly wide-ranging sections taken together, not a
statement made directly in the text. It's reasonable to say that the
standard makes this result /evident/, but that's very different from
saying it makes it /clear/. Similarly, the rules of mathematics make
it /evident/ that the equation 'x**N + y**N = z**N' has positive
integer solutions for x, y, z, and N only when N <= 2; but the
truth of this result is far from being clear. I don't have any
problem agreeing that the standard requires prototypes be supplied
only by declarations using a parameter type list; but that
requirement, even though it is present, is not expressed directly
and explicitly enough to expect there won't be some confusion.
The potential for confusion, as evidenced both by the discussion
here and by the person/group who submitted DR#317, makes the
case that language in the standard on this point is not clear.

With all due respect for those who work on defining the standard --
and my respect for them is considerable, for it is a tremendous
achievement, both for what it chooses to say and how it chooses to say
it -- when discussions come up like those that have come up in this
thread (especially when they come up repeatedly), it would be good to
give more consideration to revising or adding a clarifying statement
to make the intended meanings more direct and more explicit. To give
another example, there has been recently and apparently again just now
in another thread, questions raised about whether (char*) arguments
can be passed for (void*) paramters to printf(). Judging by past
postings, the sentiments of the committee are different from the views
of many of the readers here. But the readers here aren't stupid, and
when many smart people reach a "wrong" conclusion, that should send
a fairly strong signal that clarifying language is warranted.

I also want to point out an example on the other side of the fence.
I noticed that the released draft of the C01x standard has new
language for execution sequencing (replacing the old "sequence point"
language). This new language looks like a big improvement over
the old description, which has provoked many a spirited discussion
over the years. So I hope that this is an indication that these
discussions can induce clarifying changes in some cases.