Re: C99 conformance bug in gcc-3.1

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 30-May-2002, Joseph S. Myers <jsm28@cam.ac.uk> wrote:
> On Thu, 30 May 2002, Fergus Henderson wrote:
> 
> > GNU C permits structs with zero-sized array members to be elements of
> > other arrays or structs, and thus requires them to be padded to ensure
> 
> All cases where flexible array member constraints aren't checked are
> (documented) bugs, not extensions that should be used, except for the
> single documented extension of allowing static initialization.

That sounds like a reasonable position, for flexible array members.

But, on the other hand, the ability to put zero-sized array members in
structs or arrays is something that GNU C has supported for years.
I think it would be undesirable to prohibit that now.

Furthermore, it would be odd for zero-sized array members to behave
differently than flexible array members.  (Is that what you are arguing
for?)

So, this leaves a choice:

	(1) Hope that WG14 will modify the relevant text in C99
	    to permit structs with flexible array members to be layed out
	    the way that current implementations (GNU C, Compaq C,
	    Sun C, and Dave Prosser's C implementation) do.
	    Then zero-sized array members and flexible
	    array members can behave the same, modulo diagnostics,
	    and GNU C can keep its current layout for both.

	(2) Have zero-sized array members behave differently than
	    flexible array members.  Change the layout of structs
	    with flexible array members to match the C99 specification,
	    but leave the layout of structs with zero-sized array members
	    as it currently stands.

	(3) Add additional restrictions on how zero-sized array members
	    can be used, possibly breaking existing code,
	    and change the layout for both zero-sized array members and
	    flexible array members to match the C99 specification,
	    again possibly breaking existing code.

	(4) Ignore the C99 conformance bug.

Obviously (4) is very undesirable.
And (2) and (3) both have significant drawbacks: (2) complicates
the GNU C language, since there would be two very similar constructs
with slightly different semantics, while (3) would break backwards
compatibility.

IMHO (1) is the best option.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.