This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH to cp/decl.c: Timing name lookup
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Jason Merrill <jason at redhat dot com>, "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, <gdr at integrable-solutions dot net>, <gcc-patches at gcc dot gnu dot org>, <pinskia at physics dot uc dot edu>, <zack at codesourcery dot com>
- Date: Thu, 13 Feb 2003 23:52:00 +0000 (GMT)
- Subject: Re: C++ PATCH to cp/decl.c: Timing name lookup
On Thu, 13 Feb 2003, Neil Booth wrote:
> > And we ought to get rid of GCC's C extensions that allow such things
> > without -pedantic.
>
> Can't we get rid of them altogether, unless there's a good reason for
> having them (like your offsetof example)? Otherwise, it just seems like
> having useless features for the sake of it.
That's what I'm saying. At present, without -pedantic we accept them (and
with -pedantic we reject some, not all, of the invalid cases). We should
simply reject them unconditionally - not condition on pedantic, or
flag_iso, just reject them. The only extension needed ought to be
__constant_expression__ (which is unfortunately a bit ill-defined, in that
it depends on whatever a particular version is able to optimise).
Even without extensions, keeping track of exactly what is a constant
expression in C99 is complicated enough (C90 is simpler; as is C++ though
there are some C++ DRs about bugs in the specification). Remember 0.0
isn't an integer constant expression; (int)0.0, (_Bool)0.0 and (enum
foo)0.0 are, but (int)+0.0 and (int)(double)0.0 and (0.0 != 0) aren't. A
function call can in C99 appear in an unevaluated subexpression - so (0 ?
(((int (*)(void))0)()) : 0) is an integer constant expression, but (0 ?
foo() : 0) isn't since foo isn't one of the permitted operands.... That
is, some things (unpermitted operands) prevent the whole expression from
ever being constant unless inside sizeof, but others might be OK if in an
unevaluated subexpression. Maybe all the oddities with unevaluated
subexpressions are defects - arising from changes in C99 to allow for VLAs
- but we couldn't agree that they were in the UK C Panel so never
submitted a DR about them though one had been drafted (about the simpler
cases, I hadn't realised the more bizarre cases like the function calls
then). It may be best to try again to get a DR raised before actually
implementing the C99 rules in GCC.
--
Joseph S. Myers
jsm28@cam.ac.uk