Re: Further C front end tests

[Zack Weinberg <zack at codesourcery dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
...
> after "void *p;", I think p[0] should be unconditionally a hard error as a 
> constraint violation (unlike *p, which is required to be accepted): at 
> present it ends up a hard error with -pedantic-errors only, for arithmetic 
> on a void * pointer.

Hang on, this doesn't make sense.  Given void *p, the standard C
definition of array indexing, and GCC's extension whereby void * is
treated as char * for purposes of pointer arithmetic, p[0] reduces to
*p.  If dereferencing a pointer to void is a constraint violation,
then they are *both* ill-formed in our extended C.  If it isn't,
neither is.

I am not sure whether dereferencing a pointer to void is a constraint
violation or just compile-time undefined behavior.  The most definite
prohibition I can find is Â6.3.2.2, "The (nonexistent) value of [an
expression with type _void_] shall not be used in any way", and that
would seem to allow dereferencing a pointer-to-void as long as the
result is not used.

Mind you, I don't like the arithmetic-on-void* extension, but we
cannot abruptly remove it; it is extensively used in the wild, e.g. in
the Linux kernel.  We would have to go through a formal N-release
deprecation cycle.  Furthermore, should we choose to do that, we need
to do it all at once, not piecemeal.

zw