«

Marcin Grzegorczyk <> writes:

> Tim Rentsch wrote:
>> Marcin Grzegorczyk<> writes:
>>> Consider this example:
>>>
>>> struct { unsigned x:5, y:6, z:7; } s;
>>> unsigned u;
>>> /* ... */
>>> s.x = (s.x++, u);
>>>
>>> In a typical implementation, either update of `s.x` will require
>>> reading the container object first. Now the question is: is that read
>>> access considered a part of the side effect, or may it be considered a
>>> part of value computation (as defined in 5.1.2.3)? If the latter,
>>> then the behaviour is undefined.
>>
>> That may be true but it's irrelevant to the semantics defined for
>> the abstract machine. In the abstract machine, assigning to an
>> lvalue commences at the point of evaluting the assignment operator,
>> not before.
>
> 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.

Tim Rentsch wrote:
> Marcin Grzegorczyk<> writes:
>> Tim Rentsch wrote:
>>> Marcin Grzegorczyk<> writes:
>>>> Consider this example:
>>>>
>>>> struct { unsigned x:5, y:6, z:7; } s;
>>>> unsigned u;
>>>> /* ... */
>>>> s.x = (s.x++, u);
>>>>
>>>> In a typical implementation, either update of `s.x` will require
>>>> reading the container object first. Now the question is: is that read
>>>> access considered a part of the side effect, or may it be considered a
>>>> part of value computation (as defined in 5.1.2.3)? If the latter,
>>>> then the behaviour is undefined.
>>>
>>> That may be true but it's irrelevant to the semantics defined for
>>> the abstract machine. In the abstract machine, assigning to an
>>> lvalue commences at the point of evaluting the assignment operator,
>>> not before.
>>
>> 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?

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 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,

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.
--
Marcin Grzegorczyk

Luca Forlizzi <> writes:

> On 4 Gen, 03:06, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> Marcin Grzegorczyk <mgrze...@poczta.onet.pl> writes:
>
>> > 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.

Marcin Grzegorczyk <> writes:

> Tim Rentsch wrote:
>> Marcin Grzegorczyk<> writes:
>>> Tim Rentsch wrote:
>>>> Marcin Grzegorczyk<> writes:
>>>>> Consider this example:
>>>>>
>>>>> struct { unsigned x:5, y:6, z:7; } s;
>>>>> unsigned u;
>>>>> /* ... */
>>>>> s.x = (s.x++, u);
>>>>>
>>>>> In a typical implementation, either update of `s.x` will require
>>>>> reading the container object first. Now the question is: is that read
>>>>> access considered a part of the side effect, or may it be considered a
>>>>> part of value computation (as defined in 5.1.2.3)? If the latter,
>>>>> then the behaviour is undefined.
>>>>
>>>> That may be true but it's irrelevant to the semantics defined for
>>>> the abstract machine. In the abstract machine, assigning to an
>>>> lvalue commences at the point of evaluting the assignment operator,
>>>> not before.
>>>
>>> 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?
>
> 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.

On 28 Gen, 00:15, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Luca Forlizzi <luca.forli...@gmail.com> writes:
> > On 4 Gen, 03:06, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> >> Marcin Grzegorczyk <mgrze...@poczta.onet.pl> writes:
>
> >> > 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.

On Sat, 29 Jan 2011 02:17:10 -0800, Luca Forlizzi wrote:
> On 28 Gen, 00:15, Tim Rentsch wrote:
>> 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.)

--
jiw

On 29 Gen, 22:19, James Waldby <n...@valid.invalid> wrote:
> 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!