Why is this expression detected as undefined by GCC, Splint?

[Tim Rentsch]

That's your interpretation.

Yes, it is my opinion on this point that my comment about
assignment semantics and the abstract machine is the only
sensible reading of the relevant portions in the Standard, and
that it matches what the authors intended and expect. It is
also, as far as I know, the opinion of every other person
informed on the subject, including those who have taken the
time to try to write formal descriptions of the semantics
of C's sequencing rules.

Do you have anything to offer here other than a statement of
your own opinion, which seems to be at odds with everyone
else who is informed on the subject?

I think this issue deserves a clarification from the WG14.
(How does one go about filing a Defect Report, anyway?)

I would say such clarification already exists in the new language
regarding sequencing given in N1425 etc, of which Larry Jones has
said that it expresses what the group intended all along. But
don't let that stop you from filing a Defect Report, and please
post something in the newsgroup if you do file one.

 

[Marcin Grzegorczyk]

Yes, it is my opinion on this point that my comment about
assignment semantics and the abstract machine is the only
sensible reading of the relevant portions in the Standard, and
that it matches what the authors intended and expect. It is
also, as far as I know, the opinion of every other person
informed on the subject, including those who have taken the
time to try to write formal descriptions of the semantics
of C's sequencing rules.

Do you have anything to offer here other than a statement of
your own opinion, which seems to be at odds with everyone
else who is informed on the subject?

No. It just occurred to me, while analysing the code examples that
started this thread, that the text of the Standard is not entirely clear
on this point (at least to me). And if I could interpret the Standard
in a way suggesting that my bit-field example leads to undefined
behaviour, so could someone who, say, implemented a C compiler, I guess.
That's why, as a programmer, I'd like to know if the Committee
believes there is, indeed, a possibility of UB there.

6.5.16.1p3 may be particularly relevant in this context; it specifies a
semantic constraint on the assignment operator that does not follow from
the abstract machine and sequencing constraints.

I would say such clarification already exists in the new language
regarding sequencing given in N1425 etc, of which Larry Jones has
said that it expresses what the group intended all along. But
don't let that stop you from filing a Defect Report,

I'd like to, but I have no idea how one does that...

and please
post something in the newsgroup if you do file one.

Sure.
*If*.

As a matter of fact, there are a few other issues I'd like to be
clarified as well; I mentioned one of those (compatibility of
structures with FAMs) not long ago, in a thread cross-posted to comp.std.c.

 

[Tim Rentsch]

IIRC, Larry Jones said on comp.std.c something to the effect of "the
new sequencing specification is supposed to say what we always meant
the Standard to say" (sorry if I grossly misquote you, Larry) ;-)

He did but this case isn't what he was talking about. The old
rules (1) were somewhat unclear about how function calls worked,
and (2) arguably made undefined cases like 'a[a[0]] = 2;', where
initially a[0] == 0. Expressions like the example with sequence

I am aware of the issue (2) (a[a[0]]=2; where a[0]=0), it was
discussed deeply in a thread some months ago. Which aspects of
function calls are clarified by the new wording in the future standard
drafts?

That function calls are evaluated atomically (ie, either
completely before or completely after) any parallel
subexpressions in the same expression as the function call.

 

[Tim Rentsch]

No. It just occurred to me, while analysing the code examples that
started this thread, that the text of the Standard is not entirely
clear on this point (at least to me). And if I could interpret the
Standard in a way suggesting that my bit-field example leads to
undefined behaviour, so could someone who, say, implemented a C
compiler, I guess. That's why, as a programmer, I'd like to know if
the Committee believes there is, indeed, a possibility of UB there.

I expect most implementors read more than just the Standard, in
particular the various published documents on the open-std.org
website giving formal specifications for how sequence points work.
Even though these documents are not normative, since they were
written by people who participated regularly in the committee
meetings, they are pretty good indicators of what the Standard's
authors intended.

6.5.16.1p3 may be particularly relevant in this context; it specifies
a semantic constraint on the assignment operator that does not follow
from the abstract machine and sequencing constraints.

A little thought should show that this paragraph isn't relevant to
the question here about sequence points, since any expression that
occurs before a sequence point doesn't meet the conditions of a
to-be-assigned value that is discussed in 6.5.16.1p3.

 

[Luca Forlizzi]

IIRC, Larry Jones said on comp.std.c something to the effect of "the
new sequencing specification is supposed to say what we always meant
the Standard to say" (sorry if I grossly misquote you, Larry) ;-)
He did but this case isn't what he was talking about.  The old
rules (1) were somewhat unclear about how function calls worked,
and (2) arguably made undefined cases like 'a[a[0]] = 2;', where
initially a[0] == 0.  Expressions like the example with sequence

I am aware of the issue (2) (a[a[0]]=2; where a[0]=0), it was
discussed deeply in a thread some months ago. Which aspects of
function calls are clarified by the new wording in the future standard
drafts?

That function calls are evaluated atomically (ie, either
completely before or completely after) any parallel
subexpressions in the same expression as the function call.

Ah, ok. Now I recall that the "atomicality" of function calls is not
clearly stated in the current standard, but it is a property assumed
by the Standard Committee in answering DRs (for instance the 087), so
I consider that the instent of the current standard is that function
calls are atomical.

 

[James Waldby]

Luca Forlizzi <writes: ....

[...] Which aspects of function calls are clarified
by the new wording in the future standard drafts?

That function calls are evaluated atomically (ie, either completely
before or completely after) any parallel subexpressions in the same
expression as the function call.

Ah, ok. Now I recall that the "atomicality" of function calls is not
clearly stated in the current standard, but it is a property assumed by
the Standard Committee in answering DRs (for instance the 087), so I
consider that the intent of the current standard is that function calls
are atomical.

"Atomicality" and "atomical" are not well-formed English words.
The following phrases are proper:
... the atomicity of function calls ...
... function calls are atomic ...

Also, Rentsch's phrase
... calls are evaluated atomically ...
is proper. ("Atomicly" looks like it would have the right
meaning and be less verbose, but it isn't an English word.)

 

[Luca Forlizzi]

On Sat, 29 Jan 2011 02:17:10 -0800, Luca Forlizzi wrote:

"Atomicality" and "atomical" are not well-formed English words.
The following phrases are proper:
   ... the atomicity of function calls ...
   ... function calls are atomic ...

Also, Rentsch's phrase
   ... calls are evaluated atomically ...
is proper.  ("Atomicly" looks like it would have the right
meaning and be less verbose, but it isn't an English word.)

oh.. I apologise. Indeed I had a doubt, but I was in a hurry at the
time I did the post, so I didn't check.
Thanks you very much!