Re: 80386 C compiler

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