This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC/RFHelp: c-decl.c rewrite - almost but not quite

On Tue, 16 Mar 2004, Zack Weinberg wrote:

> I think that both here and in 6326 you are making a distinction
> without a difference.  I think we're allowed to reject the sample
> translation unit in 6326 (compile-time undefined behavior) and I don't

We can reject it because the invalid calls are in main and so _every_
possible execution is run-time undefined (DR#109).

> see value in treating () in a function definition differently from (void).

In C, as opposed to C++, only parameter type lists create a type that
includes a prototype.  Other declarations, including (), create a type 
that does not include a prototype; there are some limited compatibility 
checks for these described in (can't match a prototype with 
..., can't match a type with default promotions, old-style definition must 
match prototype).

The standard may not explicitly say that a type that includes a prototype
is given only if a parameter type list is present, but it never says it is
given otherwise, and I think this is a case where the intent of C is
generally understood and does not contradict the wording of the standard
(unlike, say, the definition of lvalues, where the intent of C is
generally understood and it is generally understood that both C90 and C99
fail to capture it in different ways and K&R1 came closer).  I can see the
scope for potential defect reports arising from, which I shall
prepare, but the case here seems to be just failure to make explicit that
an "if" is an "if and only if".

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]