Velocity Reviews > x=r=y; // With r volatile. Is r read?

# x=r=y; // With r volatile. Is r read?

Tim Rentsch
Guest
Posts: n/a

 03-11-2011
Spiros Bousbouras <(E-Mail Removed)> writes:

> On Tue, 08 Mar 2011 14:58:41 -0500
> Kenneth Brody <(E-Mail Removed)> wrote:
>> On 3/8/2011 1:09 PM, Chad wrote:
>> [...]
>> > The part I'm kind of fuzzy about is the ++b
>> >
>> > in
>> >
>> > int k = a++ + ++b;
>> >
>> > The result of the preincrement operator to (applied) b is also a side
>> > effect. However, I think this side effect is applied before the
>> > statement completes. Ie, both b in incremented by one and the side
>> > effect is applied to b. Whereas side effect of a++ is applied *after*
>> > the statement completes.

>>
>> No. Both the increments of a and of b are guaranteed to take place before
>> the statement completes. (Or, more technically, before the next "sequence
>> point".) When, exactly, during the execution of the statement, the
>> increments take place is not specified by the Standard.
>>
>> However, the meaning of "a++" is "the value of a before the increment", and
>> "++b" is "the value of b after the increment". However, that does not
>> necessarily mean that "b" actually has been incremented by the time the
>> value of "++b" is used, nor that "a" won't be incremented before the value
>>
>> In other words, this pseudo-code is a perfectly valid implementation of the
>> above code:
>>
>> ; extern int a,b;
>> ; int k = a++ + ++b;
>>
>> incr k
>> incr a
>> incr b
>>
>> In fact, I believe this implementation is just as valid:
>>
>> incr a
>> incr b
>>
>> Despite the fact that we are using the value of "a++" after the increment,
>> and "++b" before the increment, the result is indistinguishable from the
>> other way around. (However, there may be a problem with this implementation
>> for values of a==INT_MAX and b<0 due to the overflow in "a++".

>
> If a==INT_MAX then a++ produces undefined behavior so all
> implementations are valid.

What you mean is that an implementation could exhibit any
particular behavior and still be a conforming implmentation.

If an implementation chooses to define the behavior on overflow as
doing a particular something (which the implementation is free to
do), and then does something else, it seems fair to say the
implementation is not conforming, at least in spirit if not in
letter. (I can't find any statement in the Standard that says the
required documentation for extensions and implementation-defined
behaviors must be accurate, but certainly it seems reasonable
that such accuracy is expected.)

Phil Carmody
Guest
Posts: n/a

 03-13-2011
Noob <root@127.0.0.1> writes:

> Francois Grieu wrote:
>
> > extern volatile unsigned r;
> > unsigned x,y;
> >
> > void test(void)
> > {
> > x=r=y;
> > }
> >
> > What happens:
> > - y is read, written in r and in x.
> > - y is read, written in r; then r is read, written in x.
> > - any of the above.
> > - other..

>
> On a related note, I'd like to point to an (IMHO) interesting paper.
>
> Volatiles Are Miscompiled, and What to Do about It
> http://www.cs.utah.edu/~regehr/paper...8-preprint.pdf

And I'd like to point out that if it's the paper I'm thinking of,
it has some misunderstandings of what volatile actually means.
Trawl your favourite usenet archives for previous discussions
of this.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

Spiros Bousbouras
Guest
Posts: n/a

 03-17-2011
On Fri, 11 Mar 2011 12:59:03 -0800
Tim Rentsch <(E-Mail Removed)> wrote:
> Spiros Bousbouras <(E-Mail Removed)> writes:
>
> > On Tue, 08 Mar 2011 14:58:41 -0500
> > Kenneth Brody <(E-Mail Removed)> wrote:
> >>
> >> ; extern int a,b;
> >> ; int k = a++ + ++b;

[...]

> > If a==INT_MAX then a++ produces undefined behavior so all
> > implementations are valid.

>
> What you mean is that an implementation could exhibit any
> particular behavior and still be a conforming implmentation.
>
> If an implementation chooses to define the behavior on overflow as
> doing a particular something (which the implementation is free to
> do), and then does something else, it seems fair to say the
> implementation is not conforming, at least in spirit if not in
> letter.

I wouldn't say that it's non conforming either in spirit or in letter ,
I would simply say that the documentation or the translator have a bug.

> (I can't find any statement in the Standard that says the
> required documentation for extensions and implementation-defined
> behaviors must be accurate, but certainly it seems reasonable
> that such accuracy is expected.)

It is expected for reasons of common sense and usability not because
the standard says so. I wouldn't expect the standard of any language to
say that the documentation of implementations should be accurate.

Tim Rentsch
Guest
Posts: n/a

 03-17-2011
Spiros Bousbouras <(E-Mail Removed)> writes:

> On Fri, 11 Mar 2011 12:59:03 -0800
> Tim Rentsch <(E-Mail Removed)> wrote:
>> Spiros Bousbouras <(E-Mail Removed)> writes:
>>
>> > On Tue, 08 Mar 2011 14:58:41 -0500
>> > Kenneth Brody <(E-Mail Removed)> wrote:
>> >>
>> >> ; extern int a,b;
>> >> ; int k = a++ + ++b;

>
> [...]
>
>> > If a==INT_MAX then a++ produces undefined behavior so all
>> > implementations are valid.

>>
>> What you mean is that an implementation could exhibit any
>> particular behavior and still be a conforming implmentation.
>>
>> If an implementation chooses to define the behavior on overflow as
>> doing a particular something (which the implementation is free to
>> do), and then does something else, it seems fair to say the
>> implementation is not conforming, at least in spirit if not in
>> letter.

>
> I wouldn't say that it's non conforming either in spirit or in letter ,
> I would simply say that the documentation or the translator have a bug.
>
>> (I can't find any statement in the Standard that says the
>> required documentation for extensions and implementation-defined
>> behaviors must be accurate, but certainly it seems reasonable
>> that such accuracy is expected.)

>
> It is expected for reasons of common sense and usability not because
> the standard says so. I wouldn't expect the standard of any language to
> say that the documentation of implementations should be accurate.

You are entitled to your own opinions. My opinion is that the
Standard should state its requirements clearly and explicitly,
and not have to rely on any imaginative interpretations or

Spiros Bousbouras
Guest
Posts: n/a

 03-17-2011
On Thu, 17 Mar 2011 14:58:35 -0700
Tim Rentsch <(E-Mail Removed)> wrote:
> Spiros Bousbouras <(E-Mail Removed)> writes:
>
> > On Fri, 11 Mar 2011 12:59:03 -0800
> > Tim Rentsch <(E-Mail Removed)> wrote:
> >> Spiros Bousbouras <(E-Mail Removed)> writes:
> >>
> >> > On Tue, 08 Mar 2011 14:58:41 -0500
> >> > Kenneth Brody <(E-Mail Removed)> wrote:
> >> >>
> >> >> ; extern int a,b;
> >> >> ; int k = a++ + ++b;

> >
> > [...]
> >
> >> > If a==INT_MAX then a++ produces undefined behavior so all
> >> > implementations are valid.
> >>
> >> What you mean is that an implementation could exhibit any
> >> particular behavior and still be a conforming implmentation.
> >>
> >> If an implementation chooses to define the behavior on overflow as
> >> doing a particular something (which the implementation is free to
> >> do), and then does something else, it seems fair to say the
> >> implementation is not conforming, at least in spirit if not in
> >> letter.

> >
> > I wouldn't say that it's non conforming either in spirit or in letter ,
> > I would simply say that the documentation or the translator have a bug.
> >
> >> (I can't find any statement in the Standard that says the
> >> required documentation for extensions and implementation-defined
> >> behaviors must be accurate, but certainly it seems reasonable
> >> that such accuracy is expected.)

> >
> > It is expected for reasons of common sense and usability not because
> > the standard says so. I wouldn't expect the standard of any language to
> > say that the documentation of implementations should be accurate.

>
> You are entitled to your own opinions. My opinion is that the
> Standard should state its requirements clearly and explicitly,
> and not have to rely on any imaginative interpretations or

I agree. But I don't understand which imaginative interpretations or
reading between the lines you have in mind.

James Kuyper
Guest
Posts: n/a

 03-19-2011
On 03/17/2011 07:07 PM, Spiros Bousbouras wrote:
> On Thu, 17 Mar 2011 14:58:35 -0700
> Tim Rentsch<(E-Mail Removed)> wrote:

....
>> You are entitled to your own opinions. My opinion is that the
>> Standard should state its requirements clearly and explicitly,
>> and not have to rely on any imaginative interpretations or

>
> I agree. But I don't understand which imaginative interpretations or
> reading between the lines you have in mind.

If the standard requires that something be documented, but a given
implementation's documentation documents it incorrectly, then the
correct thing is not documented. Therefore, the behavior that is
supposed to be documented, isn't, and the implementation therefore fails
to conform. Don't expect Tim to accept this argument; he can go on
forever arguing over such issues.

There's a flaw in this interpretation: what if an implementation
correctly documents everything it's supposed to document, and ALSO
documents one or more items incorrectly, and fails to provide any
mechanism for distinguishing the correct documentation from the
incorrect documentation. By my interpretation, that implementation has
met the standard's documentation requirements, which is rather problematic.

This is just a particular example of a more general problem: the
standard's documentation requirements are too weak to guarantee that the
documentation is useful. In particular, the standard does not specify
which language the documentation should be in; it doesn't require that
the documentation be available in any language that you know how to
read; it doesn't even require that it be written in a language than
anyone knows how to read. This is all left as a matter of Quality of
Implementation" (QoI). It is no more (or less) problematic than the fact
that the standard fails to impose any performance requirements on C
implementations: an implementation that takes one billion years to
execute the statement i++ could still be fully conforming (though
conformance testing could be very time consuming .
--
James Kuyper

Tim Rentsch
Guest
Posts: n/a

 04-10-2011
James Kuyper <(E-Mail Removed)> writes:

> On 03/17/2011 07:07 PM, Spiros Bousbouras wrote:
>> On Thu, 17 Mar 2011 14:58:35 -0700
>> Tim Rentsch<(E-Mail Removed)> wrote:

> ...
>>> You are entitled to your own opinions. My opinion is that the
>>> Standard should state its requirements clearly and explicitly,
>>> and not have to rely on any imaginative interpretations or

>>
>> I agree. But I don't understand which imaginative interpretations or
>> reading between the lines you have in mind.

>
> If the standard requires that something be documented, but a given
> implementation's documentation documents it incorrectly, then the
> correct thing is not documented. Therefore, the behavior that is
> supposed to be documented, isn't, and the implementation therefore
> fails to conform. Don't expect Tim to accept this argument; he can go
> on forever arguing over such issues.

Apparently Mr. Kuyper is bothered by being asked if he
can offer any facts in support of his opinions. Even
so it seems poor form to ignore my questions given in
direct response to his postings and then snipe at me
off in a response to someone else.