empty initialization of zero-length array

[Kaoru Fukui]

Hi!

See the mails and subject.


Kaoru




From: Alexandre Oliva <aoliva@redhat.com>
To: sailer@ife.ee.ethz.ch
Subject: Re: kerne-2.4.0-test13pre3 with gcc-2.97
Date: 24 Dec 2000 16:08:08 -0200
Cc: Kaoru Fukui <k_fukui@highway.ne.jp>, linuxppc-dev@lists.linuxppc.org,gcc
@gcc.gnu.org

> 
> On Dec 24, 2000, Thomas Sailer <sailer@ife.ee.ethz.ch> wrote:
> 
> > Alexandre Oliva wrote:
> 
> >> This change (and apparently all other changes you've made) are
> >> definitely wrong.  Zero-sized arrays as the last element of a
> >> structure used to be an extension in GCC 2.95.2, that has been adopted
> >> by C99 with a slightly different syntax, that GCC CVS supports: just
> >> remove the `0' from between the braces.
> 
> > Which is not backward compatible, unfortunately.
> 
> Indeed.  I wish we had maintained the old syntax for
> backward-compatibility, even if with a deprecation warning.
> 



From: Thomas Sailer <sailer@ife.ee.ethz.ch>
To: Alexandre Oliva <aoliva@redhat.com>
Subject: Re: kerne-2.4.0-test13pre3 with gcc-2.97
Date: Sun, 24 Dec 2000 16:19:23 +0100
CC: Kaoru Fukui <k_fukui@highway.ne.jp>, linuxppc-dev@lists.linuxppc.org,gcc
@gcc.gnu.org

> Alexandre Oliva wrote:
> > 
> > On Dec 23, 2000, Kaoru Fukui <k_fukui@highway.ne.jp> wrote:
> > 
> > > -             unsigned char b[0];
> > > +             unsigned char *b;
> > 
> > This change (and apparently all other changes you've made) are
> > definitely wrong.  Zero-sized arrays as the last element of a
> > structure used to be an extension in GCC 2.95.2, that has been adopted
> > by C99 with a slightly different syntax, that GCC CVS supports: just
> > remove the `0' from between the braces.
> 
> Which is not backward compatible, unfortunately. So the
> backward compatible fix would be "unsigned char b[1];". 
> 
> Tom
> 




From: Paul Laufer <pelaufer@csupomona.edu>
To: gcc-bugs@gcc.gnu.org
Subject: empty initialization of zero-length array
Date: Tue, 26 Dec 2000 00:52:05 -0800

> Hi,
> 
> I'm new to these lists, but according to the archives it seems that some
> changes were made to the way gcc 2.97 handles zero-length arrays some
> time in October and November. The problem is that gcc abort()s when
> initializing a zero-length array to an empty initializer.
> gcc/extend.texi does not mention that initializing a zero-length array
> with an empty initializer is forbidden, so I submit this bug report.
> Even if it were so, gcc should error, not abort.
> 
> GCC version: gcc version 2.97 20001224 i686-pc-linux-gnu
> configure options:  --enable-shared --with-gnu-as --with-gnu-ld --enable-threads
> glibc 2.1.3 (included in case it is relevant)
> 
> Sample program that demonstrates the buggy behavior:
> 
> struct foo {
>         int a;
>         char array[];
> };
> int main()
> {
>         static struct foo bar = { 0, { } };
>         return bar.a;
> }
> 
> hal9000:~> gcc -v -save-temps test.c
> Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/specs
> Configured with: ../configure --enable-shared --with-gnu-as --with-gnu-ld -
-enable-threads
> gcc version 2.97 20001224 (experimental)
>  /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/cpp0 -lang-c -v -D__GNUC__=
2 -D__GNUC_MINOR__=97 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__
ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED
__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -
D__tune_pentiumpro__ test.c test.i
> GNU CPP version 2.97 20001224 (experimental) (cpplib) (i386 Linux/ELF)
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/include
>  /usr/local/i686-pc-linux-gnu/include
>  /usr/include
> End of search list.
>  /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/cc1 -fpreprocessed test.i -
quiet -dumpbase test.c -version -o test.s
> GNU C version 2.97 20001224 (experimental) (i686-pc-linux-gnu) compiled by 
GNU C version 2.97 20001224 (experimental).
> test.c: In function `main':
> test.c:26: Internal compiler error in array_size_for_constructor, at varasm.c:
4461
> Please submit a full bug report.
>  See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> hal9000:~> 
> 
> The compilation aborts in gcc/varasm.c here (around line 4460):
> 
>   /* ??? I'm fairly certain if there were no elements, we shouldn't have
>      created the constructor in the first place.  */
>   if (max_index == NULL_TREE)
>     abort ();
> 
> If the "abort ();" is changed to "return 0;" then gcc compiles the file
> and produces correct output, as compared with that produced when the empty
> initializer is left out (which gcc gives missing initializer warning but
> then effectively initializes the zero-length array with a empty
> initializer).
> 
> Initialization of a zero-length array with an empty initializer is used
> at least in the linux firewall code (see
> linux/net/ipv4/netfilter/ip_tables.c line 1360 in linux 2.4.0-test12 for
> an example). AFAIK, in the linux firewall code the zero-length array is
> not used for the statically defined structure (hence the empty
> initializer), but it is used for dynamically allocated structures of the
> same type. The availability of the statically initialized structure
> greatly simplifies some of the code. I can explain this more if required.
> 
> But the current gcc behavior is simply wrong. I would like to see gcc
> support initialization of zero-length arrays to empty initalizers or see
> a good explaination of why this is a bad idea :-)
> 
> Thank you all for your time and a wonderful compiler!
> Paul Laufer
> 
> P.S. This causes gcc to die with segfault (same system as above):
> 
> union foo {     
>         int a;  
>         char array[0];
> } u = {0};
> 
> hal9000:~> gcc -o test.o -c test.c   
> test.c:23: Internal error: Segmentation fault.
> Please submit a full bug report.
>  See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> hal9000:~> 
> 
> Seems related to this comment in gcc/c-decl.c made by Richard Henderson:
> 
>             /* ??? Need to check somewhere that this is a structure
>                and not a union, that this field is last, and that 
>                this structure has at least one other named member.  */
> 
>