Re: 80386 C compiler

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.