This is the mail archive of the
mailing list for the GCC project.
Re: PATCH Re: c enable-checking failure
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: PATCH Re: c enable-checking failure
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Mon, 13 Jul 1998 15:11:33 -0700
- cc: law at cygnus dot com, Richard Henderson <rth at cygnus dot com>, egcs-patches at cygnus dot com
I don't have the C standard handy, but the C++ standard says
The C definition is substantially similar.
so the change was intended to prevent comma expressions from being null
pointer constants, which is correct. However, as you say, this is not
appropriate for all uses of non_lvalue. Has this been broken since 1993?
Does this seem like an appropriate fix?
Sun Jul 12 01:27:05 1998 Jason Merrill <email@example.com>
* fold-const.c (non_lvalue): Don't deal with null pointer
(fold, case COMPOUND_EXPR): Wrap a constant 0 in a NOP_EXPR.
The C front end calls non_lvalue in internal_build_compound_expr if the last
part of a compound expr is a constant zero. This would have to be changed
to construct a NOP_EXPR with your change. Curiously, I see no equivalent code
in the C++ front end, it isn't clear if that is a bug, maybe the c-typeck.c
code is redundant?
Otherwise, it seems reasonable to fix the current problem, but it won't fix
the general problem that we aren't handling handling null pointer constants
There are still other cases where we are accepting values that we shouldn't.
For instance this compiles without warning with -pedantic, but it should give
char *p = (i - i);
It would probably take a lot of work to get exactly correct handling of the
null pointer constant in pedantic mode. You'd have to check everyplace that
calls non_lvalue just in case, and you'd have to find everyplace in fold that
might return a zero and force it to add a NOP_EXPR if the result isn't a
valid null pointer constant.