Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #389210

Re: 80386 C compiler

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-27 19:42 +0000
  Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:59 -0500
    Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-27 21:52 +0000
      Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 18:07 -0500
        Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-30 01:30 +0000
          Re: 80386 C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 21:00 -0800
          Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-30 09:00 -0500
  Re: 80386 C compiler David Brown <david.brown@hesbynett.no> - 2024-11-28 09:12 +0100

csiph-web