Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Sat, 30 Nov 2024 01:30:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <20241128201403.206@kylheku.com>
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>
Injection-Date: Sat, 30 Nov 2024 02:30:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="84a72cb3b7aebe0fd5d378971e416a73";
	logging-data="1414421"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18h7E74m4NL5k3p6OfB69l9C5tMu1MSiGU="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:rjfG6HGZFsFlP3WwlcCrsgN/aqE=
Bytes: 3952

On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 11/27/24 16:52, Kaz Kylheku wrote:
>> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 11/27/24 14:42, Kaz Kylheku wrote:
>>> ...
>>>> The specification has an inconsistency, because it gives the order
>>>> in which initializations occur, yet not the order of evaluation of
>>>> the expressions that produce their values.
>>>
>>> That's not an inconsistency, it's a deliberate choice to give
>>> implementations freedom to use whichever order is most convenient.
>> 
>> Implementations are not given freedom about initialization order;
>> in { A, B } the initialization implied by A happens before B.
>> 
>> Granting a freedom here while taking it away there is inconsistent.
>> 
>> Expression B may rely on the initialization A having completed, but 
>> not on the effects of A having been settled.
>
> I'm sorry - I thought you meant that they were logically inconsistent.
> What you're actually saying is more like stylistically inconsistent.
>
> 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.

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.

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

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?

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca