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

[david dot resnick at comverse dot com]

Currently g++ requires the -pedantic flag to give a warning on a zero sized
array that is not the last field in a struct.  As far as I can see, this is
actually always a significant error if it is not the trailing field in the
struct...

Demonstration:
temp(510)$ cat zero-size-array.cpp
#include 
#include 

struct bogus
{
int a;
char b[];
int c;

} bogus;

int main(void)
{
std::cout << "size of struct bogus =" << sizeof(bogus) << std::endl;
std::cout << "offset of field b =" << offsetof(struct bogus, b) <<
std::endl;
std::cout << "offset of field c =" << offsetof(struct bogus, b) <<
std::endl;
return 0;
}
temp(511)$ g++ -Wall -o zero-size-array
zero-size-array.cppsize-array.cppe-array.cpp
temp(512)$ zero-size-array
size of struct bogus =8
offset of field b =4
offset of field c =4
temp(513)$ g++ -Wall  -pedantic -o zero-size-array
zero-size-array.cppize-array.cpp
zero-size-array.cpp:7: error: ISO C++ forbids zero-size array 'b'
temp(514)$ g++ --version
g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)

-David


-- 
   Summary: g++ should warn or error on internal 0 size array in
struct
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot resnick at comverse dot com


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

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

[david dot resnick at comverse dot com]

--- Comment #2 from david dot resnick at comverse dot com  2009-11-20 18:38 
---
(In reply to comment #1)
> Looks like this is for compatibility with GNU C, which allows it, but only in
> the form char b[0] not char b[]

b[] seems simply broken unless last in an array for the C99 "flexible array
member" type stuff, no?  I'm not really convinced about the merits/utility of
b[0] as an internal struct field either, it is an odd way to make a union
maybe?

In standard C, a size 0 array is forbidden, at least in C99 doc I have handy,
per constraint in section 6.7.5.2 indicating:

   Constraints

   [#1] The [ and ] may delimit an expression or *.  If [ and ]
   delimit an  expression  (which  specifies  the  size  of  an
   array), it shall have an integer type.  If the expression is
   a constant expression then it shall  have  a  value  greater
   than  zero.   The element type shall not be an incomplete or
   function type.


-- 


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

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

[david dot resnick at comverse dot com]

--- Comment #4 from david dot resnick at comverse dot com  2009-11-20 18:56 
---
(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.

-David


-- 


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

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

[david dot resnick at comverse dot com]

--- 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