Sujet : Re: 80386 C compiler
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 28. Nov 2024, 01:45:17
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <86zflkp4o2.fsf@linuxsc.com>
References : 1 2 3 4 5 6 7
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Keith Thompson <Keith.S.Thompson+
u@gmail.com> writes:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
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,
but C99 (which I happen to have open in a PDF reader tab) stated that
"The order in which any side effects occur among the initialization list
expressions is unspecified.". This implies that there is no sequence
point between any two initializing expressions, which means we don't
know whose expression's function call takes place first.
>
N3096 (C23 draft) has :
"""
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.
"""
>
C23 is more explicit (redundant?) than C99, which doesn't mention the
lack of a sequence point. (C11 dropped sequence points, replacing them
with "sequenced before", "sequenced after", and "unsequenced", basically
a new way of describing the same semantics.)
>
Given:
>
int n = 42;
int a[] = { n++, n++ };
>
C99 could imply that the value of a is merely unspecified, either {
42, 43 } or { 43, 42 }. Though it can almost certainly be inferred
from other parts of the C99 standard that there is no sequence
point between the two evaluations of n++ (I haven't taken the time
to check).
Under C99 rules, I believe this initializer has undefined
behavior, because of more than one modification of an object
without an intervening sequence point.