Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: possible structure initialization bug
Message-ID: <6277@brl-smoke.ARPA>
Date: Wed, 12-Aug-87 12:28:34 EDT
Article-I.D.: brl-smok.6277
Posted: Wed Aug 12 12:28:34 1987
Date-Received: Fri, 14-Aug-87 06:32:04 EDT
References: <352@mcdsun.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 35

In article <352@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes:
>I'd like to solicit opinions on whether or not the code is valid pre-ANSI
>C, valid ANSI C, or not valid C.
>struct {
>    int foo[2][2];
>} bar = {
>    {1, 2, 3, 4}
>};

It's obviously not valid C -- you have provided 4 initializers in
the list for the object bar.foo[0], but that object is an aggregate
that only has two elements, bar.foo[0][0] and bar.foo[0][1].

What was probably intended should be written:
	struct {
		int foo[2][2];
	} bar = {
		{1, 2},
		{3, 4},	/* comma optional */
	};

Note that many existing compilers are overly permissive on this,
and that the intent of ANSI C will be to provide sane semantics
for the use of EITHER fully-bracketed initializer lists OR
completely unbracketed lists, with consistent but not necessarily
sane rules for the intermediate cases -- which we hope nobody will
ever be so foolish as to use.

A couple of X3J11 meetings ago, Dave Prosser and I independently
worked through the rules for an incompletely-bracketed case, and
came up with the same answer, as well as a conviction that the
rules were complete and consistent.  One or two other people
agreed with us, and most of the rest seemed as bewildered by the
initializer bracketing rules as I recently was by the lvalueness
rules.