This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 6.7.5.3#15 (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 6.7.5.3#15, 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
jsm@polyomino.org.uk