Consider this

int main(void)
{
int a[10] = { a[5] = 42 };
}

What is supposed to happen in the above initialization? Is the standard
sufficiently specified to tell? Is it undefined behavior?

I see that C standard says that the actual initializer expressions are
indeterminately sequenced with regard to each other (and their ordering
is not necessarily the same as the order in which the initializer values
are actually stored into the destination object). But it is not clear
how this interoperates with the implied zero-initialization of the tail
portion of the array.

It is clear (assuming for a second there's no UB in the above) that the
above declaration actually initializes `a[0]`. But what about `a[5]`?

I see that most compilers end up with `42` in `a[0]` and `a[5]`. This is
natural to expect since their intended semantics is probably to
zero-initialize the whole array _before_ performing any other
initialization. But I suspect that it is theoretically possible that
some implementation might decide to fill the tail (or the "holes", in
more general case) with zeros _after_ performing all explicit
initializations. This latter approach would result in zero in `a[5]`.

Or does the lack of sequencing here leads to UB?

P.S. I seem to vaguely recall that "tricks" like these (i.e. assigning
or even referring to the object being declared in its own initializer)
were outlawed or planned to be outlawed somewhere somehow, but I don't
remember where and how. C++ perhaps?

--
Best regards,
Andrey Tarasevich

On 19/04/2022 21:39, Andrey Tarasevich wrote:
>
>
> I see that most compilers end up with `42` in `a[0]` and `a[5]`.

C++ in Visual Studio (std 14, 17 and 20) gives just a[0] = 42. The
program I wrote { slightly different from the norm} is this (This is not
vector declaration either;  No vector header is included in the program
but vector commands can be used to insert elements or delete elements ):

#include <iostream>
#include <array>

using namespace std;

int main(void)
{ array<int, 10> a = { a[5] = 42};

for (int i = 0; i < 10; i++)
{
cout << a[i] << " ";
}
cout << endl;
return 0;
}

clang command line issues a warning " variable 'a' is uninitialized when
used within its own initialization ";

GCC also gives some/lots errors that I didn't bother to read!!

I always thought that initialising the first item in an array is always
mandatory before initialising other items. However, I don't read
standards and I don't have a copy either. I just use books and "Common
Sense & Logic". I know this is a loaded statement and I have no interest
to argue about it here!

On 4/19/2022 3:18 PM, Sams Lara wrote:
> On 19/04/2022 21:39, Andrey Tarasevich wrote:
>>
>>
>> I see that most compilers end up with `42` in `a[0]` and `a[5]`.
>
>
> C++ in Visual Studio (std 14, 17 and 20) gives just a[0] = 42. The
>
>     array<int, 10> a = { a[5] = 42};

A class with user-defined initialization semantics is not a good fit in
the context of the original question.

--
Best regards,
Andrey Tarasevich

On 2022-04-19, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> Consider this
>
> int main(void)
> {
> int a[10] = { a[5] = 42 };
> }
>
> What is supposed to happen in the above initialization? Is the standard
> sufficiently specified to tell? Is it undefined behavior?

The location a[5] is both zero-initialized, and assigned.

Can we infer that these two actions are separated by sequencing?

If not, it looks like a pretty clear cut case of an object modified
twice, just like a[5] = a[5]++;

On 4/19/2022 1:39 PM, Andrey Tarasevich wrote:
> Consider this
>
> int main(void)
> {
> int a[10] = { a[5] = 42 };
> }
> ...
> I see that most compilers end up with `42` in `a[0]` and `a[5]`. This is
> natural to expect since their intended semantics is probably to
> zero-initialize the whole array _before_ performing any other
> initialization. But I suspect that it is theoretically possible that
> some implementation might decide to fill the tail (or the "holes", in
> more general case) with zeros _after_ performing all explicit
> initializations. This latter approach would result in zero in `a[5]`.
>

My attempts to persuade the compiler to abandon this "pre-initailize
with zeroes" approach in an attempt to make it override that `42` in
`a[5]` proved unsuccessful so far.

Anyway, it is interesting to note though that GCC seems to be especially
indifferent to performance-related considerations in such situations.
When faced with code like this

struct S { int a[16384]; };

struct X { struct S s; int b[8]; };

int foo(struct S *s)
{
struct X x = { *s, { x.b[3] = 42 } };
...
}

it generates the following initialization code for the local `x` in -O3 mode

mov edx, 65568
xor esi, esi
mov rdi, rsp
call memset
mov rsi, rbp
mov rdi, rsp
mov edx, 65536
call memcpy
mov DWORD PTR [rsp+65548], 42
mov DWORD PTR [rsp+65536], 42

So it effectively initializes almost entire `x`s memory twice: first
time `memset`ing it to all-zeros, then again by `memcpy`ing over it from
`*s`.

Clang's -O3 is less performance-wasteful

mov rsi, rdi
mov rdi, rsp
mov edx, 65536
call memcpy@PLT
xorps xmm0, xmm0
movups xmmword ptr [rsp + 65540], xmm0
movups xmmword ptr [rsp + 65552], xmm0
mov dword ptr [rsp + 65548], 42
mov dword ptr [rsp + 65536], 42

It doesn't waste time zeroing-out memory that will be `memcpy`ed over
anyway. It makes sure to pre-zero-out `s.b` only.

--
Best regards,
Andrey Tarasevich

Le 19/04/2022 à 22:39, Andrey Tarasevich a écrit :
> Consider this
>
>   int main(void)
>   {
>     int a[10] = { a[5] = 42 };
>   }
>
> What is supposed to happen in the above initialization? Is the standard
> sufficiently specified to tell? Is it undefined behavior?

The syntax I knew, and that is mentioned in the standard is this:

int a[10] = { [5] = 42 };

I didn't even know you could add an identifier before the [] in the
initializer. I haven't seen this mentioned in the standard, but
apparently GCC (and some other compilers) do accept it. Not sure where
that comes from, or if I missed it in the standard (if so, please
someone point me to the right paragraph.)

Anyway, incomplete initializers are supposed to have implicit zeros for
the non-specified parts, so the above I mentioned:

int a[10] = { [5] = 42 };

will initialize 'a' with all zeros except a[5], which will be 42.

Interestingly, your variant:

int a[10] = { a[5] = 42 };

will initialize 'a' with all zeros except a[0] and a[5], which will both
be 42. (Tried with GCC, but apparently confirmed by others.)

Thing is, I personally don't know what "{ a[5] = 42 }" as an initializer
is supposed to mean. Not what you had in mind, surely.

Use: "int a[10] = { [5] = 42 };" as I suggested and as is shown in the C
standard, and it will do what is expected.

Again, if anyone can point me to a reason why "int a[10] = { a[5] = 42
};" can be considered correct syntax in any way, please enlighten me!

Guillaume <message@bottle.org> writes:
> Le 19/04/2022 à 22:39, Andrey Tarasevich a écrit :
>> Consider this
>>   int main(void)
>>   {
>>     int a[10] = { a[5] = 42 };
>>   }
>> What is supposed to happen in the above initialization? Is the
>> standard sufficiently specified to tell? Is it undefined behavior?
>
> The syntax I knew, and that is mentioned in the standard is this:
>
> int a[10] = { [5] = 42 };
>
> I didn't even know you could add an identifier before the [] in the
> initializer. I haven't seen this mentioned in the standard, but
> apparently GCC (and some other compilers) do accept it. Not sure where
> that comes from, or if I missed it in the standard (if so, please
> someone point me to the right paragraph.)

This:

int a[10] = { [5] = 42 };

uses a designated initializer (a feature added in C99 IIRC).
It specifies that the initializer 42 is used to initialize element
5 of the array.

This:

int a[10] = { a[5] = 42 };

is just a conventional initializer. The expression `a[5] = 42` is the
initializer, and its value is used to initialize a[0]. It's *not* a
designated initializer with an identifier added; it's just an
expression. (And the fact that it has a side effect causes the problem
being discussed here.)

The issue being discussed in the order of evaluation. If you wrote:

int a[10] = { expr };

where `expr` is some expression with no side effects, the semantics are
straightforward; the result of evaluating `expr` is used to initialize
a[0], and the other elements are initialized to zero. But if `expr` has
the side effect of assigning a value to a[5], it's not clear whether the
assignment to a[5] specified by the evaluation of the expression, or the
assignment to a[5] that happens implicitly when all elements other than
the first are set to zero, happens first. If those two updates are not
sequenced (with the language specifying which one happens first), then
the behavior is undefined, just as for something like `i++ + i++`.

Looking at the relevant section of the standard, I see:

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.

It's not 100% clear, but I think that implies that the behavior is
undefined.

If you're writing code that's intended to be useful, don't write code
like that. If you want to initialize elements 0 and 5 to 42, just
write:

int a[10] = { [0] = 42, [5] = 42 };

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 4/21/2022 8:47 PM, Keith Thompson wrote:
> Guillaume <message@bottle.org> writes:
>> Le 19/04/2022 à 22:39, Andrey Tarasevich a écrit :
>>> Consider this
>>>   int main(void)
>>>   {
>>>     int a[10] = { a[5] = 42 };
>>>   }
<snip>
>
> If you're writing code that's intended to be useful, don't write code
> like that. If you want to initialize elements 0 and 5 to 42, just
> write:
>
> int a[10] = { [0] = 42, [5] = 42 };
>

That's the same thing I have been thinking along this thread.
I might see /some/ point if the question were like:

int n = 5; // or anything appropriately runtime-valued
int a[10] = { a[n] = 42 };

But even then, I believe the proper thing to do is:

int n = 5; // same as above
int a[10] = { 42 };
a[n] = a[0];

and let the compiler and optimizer do their job.

(For the record, I think too that the OP is UB)

Le 21/04/2022 à 20:47, Keith Thompson a écrit :
> Guillaume <message@bottle.org> writes:
>> Le 19/04/2022 à 22:39, Andrey Tarasevich a écrit :
>>> Consider this
>>>   int main(void)
>>>   {
>>>     int a[10] = { a[5] = 42 };
>>>   }
>>> What is supposed to happen in the above initialization? Is the
>>> standard sufficiently specified to tell? Is it undefined behavior?
>>
>> The syntax I knew, and that is mentioned in the standard is this:
>>
>> int a[10] = { [5] = 42 };
>>
>> I didn't even know you could add an identifier before the [] in the
>> initializer. I haven't seen this mentioned in the standard, but
>> apparently GCC (and some other compilers) do accept it. Not sure where
>> that comes from, or if I missed it in the standard (if so, please
>> someone point me to the right paragraph.)
>
> This:
>
> int a[10] = { [5] = 42 };
>
> uses a designated initializer (a feature added in C99 IIRC).
> It specifies that the initializer 42 is used to initialize element
> 5 of the array.
>
> This:
>
> int a[10] = { a[5] = 42 };
>
> is just a conventional initializer. The expression `a[5] = 42` is the
> initializer, and its value is used to initialize a[0].

Ah yes, sure!
It was looking so much like something that wasn't intended that I didn't
think of this.

I don't think it's normal that compilers (at least GCC) won't issue a
warning for this though. An expression assignment of a variable in its
initializer sounds pretty odd and probably undefined behavior?

On 4/21/2022 11:10 AM, Guillaume wrote:
> Le 19/04/2022 à 22:39, Andrey Tarasevich a écrit :
>> Consider this
>>
>>    int main(void)
>>    {
>>      int a[10] = { a[5] = 42 };
>>    }
>>
>> What is supposed to happen in the above initialization? Is the
>> standard sufficiently specified to tell? Is it undefined behavior?
>
> The syntax I knew, and that is mentioned in the standard is this:
>
> int a[10] = { [5] = 42 };
>

My original example was quite likely "inspired" by someone who tried to
remember syntax for designated initializers for array elements, but failed.

Nevertheless, my question is specifically about sequencing in

int a[10] = { a[5] = 42 };

I myself have no trouble remembering how to use designated initializers.
So, designated initializers is not what my question is about.

It is not about how to do things properly. It's is about whether the
standard unspecified/underspecified with regard to my specific example.
And if it is unspecified, whether it is intentional.

--
Best regards,
Andrey Tarasevich

>
> (For the record, I think too that the OP is UB)
>

What is UB? Google can't tell me this.

Albert Arkwright <"Albert.Arkwright "@gmail.com> writes:
>> (For the record, I think too that the OP is UB)
>
> What is UB? Google can't tell me this.

UB is undefined behavior, defined by the C standard as "behavior, upon
use of a nonportable or erroneous program construct or of erroneous
data, for which this International Standard imposes no requirements".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */