Re: 80386 C compiler

On 27/11/2024 20:42, Kaz Kylheku wrote:

On 2024-11-27, David Brown <david.brown@hesbynett.no> wrote:

On 26/11/2024 18:59, Kaz Kylheku wrote:

On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:

On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>

void fn(int a)
{
    int x[3] = { foo(), bar(), a }; /* not in C90 */

>
is in the above foo() called before bar()?

>
No, you cannot rely on that. Maybe it's fixed in a more recent standard,

>
The implication of the word "fixed" is that you think the current
standards as somehow "broken" in this respect.  Do you think that is the
case?

 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.
 Above we know that x[0] is initialized first before x[1].
 That doesn't even matter unless initializations are being observed,
which they can be if there is self-reference going on, like:
    int x[3] = { foo(), x[0] + bar(), x[0] + x[1] }
 I'm assuming this sort of thing must to be the purpose for specifying
the order of initialization.
 It looks inconsistent to me that the effects of the subobjects receiving
their inital values are ordered, but all other effects are not.
 

I don't see any justification in the standard for assuming that the initialisers are evaluated in any particular order.  The standard (at least my reading of section 6.7.9) gives a clear order to the initialisation itself (which may, of course, be re-ordered by the compiler under "as-if" rules) so that if you are using designated initialisers, it is clear that the last initialiser for each element is what counts.  Not only does that section say nothing about the order of evaluation for the parts, it says that if an initialiser is overridden, then it may not be evaluated at all (with the implication being that it might be evaluated and the result dropped).
Section 6.7.9p23:
"""
The evaluations of the initialization list expressions are indeterminately sequenced with respect to one another and thus the order in which any side effects occur is unspecified. 152)
152) In particular, the evaluation order need not be the same as the order of subobject initialization.
"""
This is very much like the evaluation of arguments to a function call - there is no specified order or sequencing between the evaluations of the arguments.