[Bug c++/42121] g++ should warn or error on internal 0 size array in struct

["david dot resnick at comverse dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from david dot resnick at comverse dot com  2009-11-23 14:15 -------
(In reply to comment #5)
> Subject: Re:  g++ should warn or error on internal 0 size
>  array in struct
> On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote:
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > In standard C, a size 0 array is forbidden, at least in C99 doc I have handy,
> > > Yes, but it's a long-standing GNU extension:
> > > http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length
> > > The C++ front end says:
> > >       /* As an extension we allow zero-sized arrays.  We always allow
> > >          them in system headers because glibc uses them.  */
> > > Maybe the C++ front-end could be made stricter, so that it accepts char b[0]
> > > (like the C front end) but not char b[] (which is a C99 flexible array member,
> > > and must be the last member)
> > 
> > OK, but if you read that link the whole rationale is to do with it being the
> > last field in a struct, not an internal member, right?  Seems like there is no
> > possible use in an internal member, and not diagnosing this as warnable means
> > you don't notice if, say, someone accidentally adds something after the
> > flexible array member.  Which happened to us, which is why I noticed this
> > issue.  If this will break existing usage, I see the reason not to change.  But
> > I'm curious what possible use a non-terminal zero sized array in a struct might
> > have.
> Several cases of C99 flexible array members that C99 does not permit are 
> only diagnosed as pedwarns-if-pedantic for C because of glibc using them.  
> (I gave an example in 
> <http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html>.)  I haven't 
> looked into why it does this.

(In reply to comment #5)
> Subject: Re:  g++ should warn or error on internal 0 size
>  array in struct
> On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote:
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > In standard C, a size 0 array is forbidden, at least in C99 doc I have handy,
> > > Yes, but it's a long-standing GNU extension:
> > > http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length
> > > The C++ front end says:
> > >       /* As an extension we allow zero-sized arrays.  We always allow
> > >          them in system headers because glibc uses them.  */
> > > Maybe the C++ front-end could be made stricter, so that it accepts char b[0]
> > > (like the C front end) but not char b[] (which is a C99 flexible array member,
> > > and must be the last member)
> > 
> > OK, but if you read that link the whole rationale is to do with it being the
> > last field in a struct, not an internal member, right?  Seems like there is no
> > possible use in an internal member, and not diagnosing this as warnable means
> > you don't notice if, say, someone accidentally adds something after the
> > flexible array member.  Which happened to us, which is why I noticed this
> > issue.  If this will break existing usage, I see the reason not to change.  But
> > I'm curious what possible use a non-terminal zero sized array in a struct might
> > have.
> Several cases of C99 flexible array members that C99 does not permit are 
> only diagnosed as pedwarns-if-pedantic for C because of glibc using them.  
> (I gave an example in 
> <http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html>.)  I haven't 
> looked into why it does this.

OK, can't argue with not breaking existing headers I suppose.  But this is to
me clearly a bogus usage.  What are the semantics of using internal zero sized
arrays in a struct?  They have the same offset as the following field and
impose alignment restrictions on it.  Do they have the same nominal
requirements as unions for usage (can't write one, read the other?)?  Or is the
idea that if they are 0 sized and internal they are not to be used for any
purpose whatsoever, and they are only not warnable because of existing usage in
glibc headers?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121