Re: Zero-length arrays

[Linus Torvalds <torvalds at transmeta dot com>]

In article <20010104103058.A19373@redhat.com>,
Richard Henderson  <rth@redhat.com> wrote:
>On Thu, Jan 04, 2001 at 01:16:11PM -0500, Richard Kenner wrote:
>> I suppose, but the issue is that a zero-length field is ambiguous.  It could
>> actually *be* zero length or it could be extendable.
>
>I don't think it is ambiguous.  Either it is extendable, or it is not
>initialized at all.  There's your front end bit -- the mere existance
>of a constructor for the field.

Wouldn't it be cleaner to just adopt the new ANSI syntax together with
the old gcc zero-array-extension. Namely something like this:

	int array[0];

is a fixed zero-size array and can be used just like any other array the
way gcc has historically done (and initializing it with anything but an
empty initializer is an _error_), while a

	int array[];

is a unspecified array, and can be initialized with anything and
absolutely _has_ to be at the end of a structure.

Because I think Kenner is right: considering [] and [0] to be the same
thing _is_ ambiguous, and means that you cannot ever warn about

	struct bad_struct {
		int a;
		int b[];
		int c;
	};

which is wrong (with your rule, you can only warn about the above when
it is actually initialized to non-empty, which may not actually ever
happen - so you miss out on a good warning). 

Is it glibc that is mixing the two kinds of arrays together? Maybe glibc
can just be changed to have something like

	#ifdef __GCC_MAJOR__ < 3
	#define __UNSPEC	0
	#else
	#define __UNSPEC	/* nada */
	#endif

and then just use 

	int array[__UNSPEC];

Or maybe glibc should just admit that they don't actually use 0-sized
arrays, what they really want is the ANSI unspecified size, and they
should just switch completely over to the plain [] (which works with
some other compilers too - not that they probably care any more than I
care about the kernel being compiled by others ;). 

			Linus