PATCH Re: c enable-checking failure

[Jim Wilson]

	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?

Apparently.

	Does this seem like an appropriate fix?

	Sun Jul 12 01:27:05 1998  Jason Merrill  <jason@yorick.cygnus.com>

	* fold-const.c (non_lvalue): Don't deal with null pointer 
	constants here.
	(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
correctly.

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
a diagnostic.

main()
{
  int i;
  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.

Jim