Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Sat, 30 Nov 2024 09:00:32 -0500
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <vif5q0$1o52o$1@dont-email.me>
References: <vhvbhf$28opb$1@dont-email.me> <vhvsm9$2bmq9$1@dont-email.me>
 <vi0dt1$2el7m$1@dont-email.me> <20241125101701.894@kylheku.com>
 <qrp9kjd09n2v3srmabqccmnsbr1r6nkm2m@4ax.com> <20241125132021.212@kylheku.com>
 <vi6qka$3umr4$1@dont-email.me> <20241127112746.171@kylheku.com>
 <vi7tmc$4ur3$4@dont-email.me> <20241127134839.469@kylheku.com>
 <vi88n4$74j9$1@dont-email.me> <20241128201403.206@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 30 Nov 2024 15:00:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f89e9b565aecdb6359055185381f3b2b";
	logging-data="1840216"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+MCT7Ex1/u/DLS6mEN3Q9U3JmwZruTNCU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MpUu80Y4CDc9Jmt78gSb12D90oY=
Content-Language: en-US
In-Reply-To: <20241128201403.206@kylheku.com>
Bytes: 5179

On 11/29/24 20:30, Kaz Kylheku wrote:
> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> In C90, the order in which the initializers were evaluated didn't
>> matter, because they were required to be static initializers. It was
>> only in C99 that they were allowed to be arbitrary expressions.
>>
>> However, in the same version of the standard, designated initializers
>> were added. Designated initializers are allowed to update elements in a
>> different order from their order in memory, and to initialize the same
>> element multiple times, with only the final initialization actually
>> occurring. This can be convenient for setting up a rule and then adding
>> exceptions to that rule.
> 
> But it simply ends up being left to right.

Why is that it a "but"? If you want to give users control over the order
of initialization, what is simpler or more natural that using the
textual order.

> Given { A, B, C }, the members are initialized in order of increasing
> offset address, corresponding to left-to-right order in the syntax.
> 
> Given { [2] = A, [1] = B, [0] = C }, they are initialized in the
> left-to-right order in the syntax: [2] first, then [1] then [0].
> 
> So we have order. And yet we don't have order; the expressions are not
> actually sequenced.

You can always make something sound contradictory or confusing by
leaving out the details that resolve the contradiction or remove the
confusion.
Yes, the initializations of the members of an aggregate object are
ordered. And also yes, the evaluations of the initializer expressions
for those objects are unordered, the same as is generally the case -
there's only a few features of C that impose order on expressions - the
semicolon at the ends of declarations or statements are the most common.
As a general way, whenever you need to order the evaluation of
expressions that would otherwise be unordered, the way to do so is
simply put them in a different declarations or statements, which often
requires creating temperaries to hold the results of intermediate
evaluations.

>> If there weren't a rule mandating the order in
>> which initializers were applied, when two or more initializers affect
>> the same object, it wouldn't be possible to be certain which one
>> overrode the others.
> 
> It would make sense for that simply to be a constraint violation;
> two initializations for the same object are being requested.

The committee felt otherwise. The standard quite explicitly says: "...
each initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject ..." (6.7.10p20). I
agree - I can see obscure situations where that rule makes the feature
more convenient. The standard also provides a relevant example where the
intended behavior depends upon this feature:

"EXAMPLE 13 Space can be "allocated" from both ends of an array by using
a single designator:
      int a[MAX] = {
            1, 3, 5, 7, 9, [MAX-5] = 8, 6, 4, 2, 0
      };

In the above, if MAX is greater than ten, there will be some zero-valued
elements in the middle; if it is less than ten, some of the values
provided by the first five initializers will be overridden by the
second five."

If you wanted the behavior to depend upon the value of MAX in precisely
the fashion provided by this feature, and this feature were not
available, the code would have to be a lot more complicated.

> There is no sequencing in the initialization: { i++, i++ } would
> be undefined behavior. Yet, you can request multiple initializations
> of the same subobject and have it safely resolved to the rightmost?

Correct. If you need initializer expressions to be ordered, you'll have
to put them in different statements or declarations.