This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR c/12446
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 03 Oct 2003 21:18:17 +0200
- Subject: Re: [PATCH] Fix PR c/12446
- Organization: Integrable Solutions
- References: <200310032103.59564.ebotcazou@libertysurf.fr>
Eric Botcazou <ebotcazou@libertysurf.fr> writes:
| Hi,
|
| This is a (minor) regression from GCC 3.0.4 present on 3.3 branch and
| mainline, introduced by this patch:
|
| http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00319.html
|
| Before the patch, GCC emitted "error: invalid use of non-lvalue array" for
|
| struct s { char c[1]; };
|
| extern struct s foo(void);
|
| void bar(void)
| {
| char *ptr = foo().c;
| }
|
| in C90 mode. After, it ICEs when trying to expand a BLKmode move.
|
|
| The patch added the comment
|
| /* Before C99, non-lvalue arrays do not decay to pointers.
| + Normally, using such an array would be invalid; but it can
| + be used correctly inside sizeof or as a statement expression.
| + Thus, do not give an error here; an error will result later. */
More precisely, before C99, it was undefined behaviour if a program
needs a non-lvalue array to decay to a pointer. Apparently, GCC
chosed to error out. It could also have chosen to accept the
construct with some warning. In effect, since the construct is now
explicitly valid in C99, I would rather we accept the construct with a
warning, or reject the construct only if -pedantic and std=c90.
At nay rate, I believe your comment should be updated to reflect the
fact that it is an juridiction area left to the compiler.
-- Gaby