Topic: volitile lvalues and sequence points
Author: kavdeiv@mail.ru (Kiril Avdeiv)
Date: Thu, 20 Sep 2001 18:50:16 GMT Raw View
The standard says that accessing an object designated by a volatile
lvalue, modifying an object are side effects.
It also says that between the previous and next sequence points a
scalar object must have its stored value modified at most once.
Why doesn't it say the same thing for accessing a volatile lvalue?
Something like "also between the previous and next sequence points a
scalar volitile object shall have its value accessed at most once by
the evaluation of an expression"?
I should be grateful to any explanation, the more low-level the
better.
Thank you
Kiril
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Jack Klein <jackklein@spamcop.net>
Date: Fri, 21 Sep 2001 03:50:15 CST Raw View
On Thu, 20 Sep 2001 18:50:16 GMT, kavdeiv@mail.ru (Kiril Avdeiv) wrote
in comp.std.c++:
> The standard says that accessing an object designated by a volatile
> lvalue, modifying an object are side effects.
>
> It also says that between the previous and next sequence points a
> scalar object must have its stored value modified at most once.
>
> Why doesn't it say the same thing for accessing a volatile lvalue?
> Something like "also between the previous and next sequence points a
> scalar volitile object shall have its value accessed at most once by
> the evaluation of an expression"?
>
> I should be grateful to any explanation, the more low-level the
> better.
>
> Thank you
> Kiril
There are several cases a volatile lvalue is accessed more than once
between sequence points. Consider:
volatile int x;
void func()
{
++x;
}
To execute the above statement the code must first access the volatile
lvalue x to read the current value, add one to that value, then access
the lvalue x again to store the result.
There are other cases that depend on the exact way the statement is
written and can cause surprising and unexpected differences from C
when volatile objects are used in programs.
Because in C++, unlike C, you can write a statement where the value of
a volatile lvalue must be accessed more than once.
Among the many, sometimes subtle, changes between C and C++, some
operators that yield rvalues in C yield lvalues in C++. Specifically
this is true of the pre-increment, pre-decrement, and all of the
assignment operators.
Consider the following:
int a, b, c;
void func()
{
a = b = c;
}
Associativity of the assignment operator makes:
a = b = c;
....equivalent to a = (b = c);
Under the C++ language standard, the result of the first assignment
operation is the lvalue of b, which must undergo lvalue to rvalue
conversion to get the rvalue to be assigned to a. In this particular
case the compiler can optimize away the second access to b to read
back the value stored, since it is entitled to assume that a
non-volatile object retains the last value stored.
Now if you change the definitions:
int a, c;
volatile int b;
....then to execute the statement a = b = c;, the compiler is not
allowed to assume that the value it stored in b is unchanged and may
be stored in a without rereading. Nor is it allowed to optimize away
the lvalue to rvalue conversion of b's value after writing it.
If b is volatile the compiler must perform the following steps:
1. lvalue to rvalue conversion of c (access the object c to retrieve
its current value).
2. Assign the value from step 1 to b (access b to write to it).
3. lvalue to rvalue conversion of b (access b to read the value it
contains).
4. Assign the value from step 3 to c.
If the compiler does not read back the value from b, it is
non-conforming.
Note that if the expression were rewritten:
b = a = c;
Then the compiler would be forbidden from accessing b more than once.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Fri, 21 Sep 2001 20:31:45 GMT Raw View
Jack Klein <jackklein@spamcop.net> wrote:
: On Thu, 20 Sep 2001 18:50:16 GMT, kavdeiv@mail.ru (Kiril Avdeiv) wrote
: in comp.std.c++:
:> The standard says that accessing an object designated by a volatile
:> lvalue, modifying an object are side effects.
:>
:> It also says that between the previous and next sequence points a
:> scalar object must have its stored value modified at most once.
:>
:> Why doesn't it say the same thing for accessing a volatile lvalue?
AFIK, modifying a volatile lvalue multiple times between sequences
points yields undefined behavior.
:> Something like "also between the previous and next sequence points a
:> scalar volitile object shall have its value accessed at most once by
:> the evaluation of an expression"?
:>
:> I should be grateful to any explanation, the more low-level the
:> better.
:>
:> Thank you
:> Kiril
: There are several cases a volatile lvalue is accessed more than once
: between sequence points. Consider:
: volatile int x;
: void func()
: {
: ++x;
: }
: To execute the above statement the code must first access the volatile
: lvalue x to read the current value, add one to that value, then access
: the lvalue x again to store the result.
AFIK, the standard doesn't prohibit accessing an lvalue more than once
between successive sequence points. Rather, undefined behavior ensues
if the lvalue is modified more than once between successive sequence
points.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]