volatile expression

[John Temples]

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects, but that
"evaluation " requires an operator. Does changing the statement to

v + 0;

or

(v);

change this?

I have some compilers which do and some compilers which do not access
"v" with the above code.

--
John W. Temples, III

[Joona I Palaste]

John Temples <us****@xargs-spam.com> scribbled the following:

Given this code: extern volatile unsigned char v; int main(void)
{
v; return 0;
} My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects, but that
"evaluation " requires an operator. Does changing the statement to v + 0; or (v); change this? I have some compilers which do and some compilers which do not access
"v" with the above code.

"v;" is very much an expression, just like "v + 0;" and "(v);" are. If a
compiler does not evaluate the value of the volatile variable v in the
expression "v;", then it is breaking the standard. The C standard
expressly dictates that any mention of a volatile variable in an
expression must result in evaluation of that variable's value.
Non-volatile variables can be optimised away in such expressions but
volatile variables cannot.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen

[Chris Torek]

In article <news:6a******* *************@i swest.net>
John Temples <us****@xargs-spam.com> wrote:
[trimmed]

extern volatile unsigned char v;
v;
My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects ...
I have some compilers which do and some compilers which do not access
"v" with the above code.

Here is a quote from a C99 draft (wording essentially unchanged from
the original 1989 ANSI C standard):

[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine, as described in 5.1.2.3.
Furthermore, at every sequence point the value last stored
in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors
mentioned previously.99 What constitutes an access to an
object that has volatile-qualified type is implementation-
defined.

The last sentence is the key here: the implementation' s documentation
must state what make something an "access" to a volatile-qualified-type
object like "v".

So, open up the documentation that came with your compiler, see
whether it says "v;" constitutes an "access", and you will find
out whether the compiler should have generated one.

(In practice, given the option, I personally would reject -- or at
least seriously downgrade -- any compiler that does not attempt to
"load v" here, regardless of the contents of the implementation
document. Of course, one must often trade off obnoxious compiler
behavior against required compiler features. But if the document
says "v;" is an access, and the compiler generates no code, you have
obvious grounds for a bug report, at least.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Dave Vandervies]

In article <ch**********@o ravannahka.hels inki.fi>,
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:

John Temples <us****@xargs-spam.com> scribbled the following:

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

[snippage]
"v;" is very much an expression, just like "v + 0;" and "(v);" are. If a
compiler does not evaluate the value of the volatile variable v in the
expression "v;", then it is breaking the standard.
Isn't that a little bit strong?
The C standard
expressly dictates that any mention of a volatile variable in an
expression must result in evaluation of that variable's value.

I thought it was any *access to* a volatile object, where exactly what
constitutes an access is implementation-defined.
So if the implementor, for some reason, chooses to not define this
as an access to v, then it's acceptable to not generate code for it.
(Whether such a compiler can be trusted to get volatile accesses in more
complex expressions "right" is of course a different matter.)
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
Practical Solution #1: Kill the programmer in question. This is
also the most satisfying solution, because it ensures that the
problem will not recur. --Ben Pfaff in comp.lang.c

[Keith Thompson]

John Temples <us****@xargs-spam.com> writes:

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects,
Yes.
but that
"evaluation " requires an operator.

[...]

Why do you think that evaluation requires an operator?

There is a flaw in the standard's definiion of "expression ".
C99 6.5p1 says:

An _expression_ is a sequence of operators and operands that
specifies computation of a value, or that designates an object or
a function, or that generates side effects, or that performs a
combination thereof.

which, taken literally, implies that v is not an expression, since it
contains no operators or operands. But it's clearly the intent that v
is an expression (see the grammar), and that it can be evaluated.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jack Klein]

On Tue, 7 Sep 2004 20:46:06 +0000 (UTC), dj******@csclub .uwaterloo.ca
(Dave Vandervies) wrote in comp.lang.c:

In article <ch**********@o ravannahka.hels inki.fi>,
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:

John Temples <us****@xargs-spam.com> scribbled the following:

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

[snippage]

"v;" is very much an expression, just like "v + 0;" and "(v);" are. If a
compiler does not evaluate the value of the volatile variable v in the
expression "v;", then it is breaking the standard.

Isn't that a little bit strong?

The C standard
expressly dictates that any mention of a volatile variable in an
expression must result in evaluation of that variable's value.

I thought it was any *access to* a volatile object, where exactly what
constitutes an access is implementation-defined.
So if the implementor, for some reason, chooses to not define this
as an access to v, then it's acceptable to not generate code for it.
(Whether such a compiler can be trusted to get volatile accesses in more
complex expressions "right" is of course a different matter.)
dave

I was going to jump on you, but it is just as well point you to Chris
Torek's detailed answer to the OP.

As for the bit about what constitutes an access to a volatile object
is implementation defined, I agree that the standard has muddied the
water for 15 years and the wording should be expanded to explain the
(claimed) intent.

Consider:

volatile unsigned char vuc [8];
/* ... */
int x = vuc [3];

On your average, everyday, Pentium, 64 bits (8 octets) are going to be
read from memory. Depending on the alignment of 'vuc', all eight of
those volatile unsigned chars may actually be read, even though all
but one of them will be ignored.

Supposedly the wording about what constitutes access is intended to
cover situations like this, meaning that a read of vuc [3] might well
cause a read of other elements. But it should clearly do a better job
of saying so.

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[John Temples]

Keith Thompson wrote:

John Temples <us****@xargs-spam.com> writes:

but that
"evaluation " requires an operator.

[...]

Why do you think that evaluation requires an operator?

The C90 standard (to which the compilers I am testing claim to comply)
defines the term "evaluation " in 6.1.5 as "An operator specifies an
operation to be performed (an _evaluation_) [...]" C99 doesn't appear
to have this explicit definition of "evaluation ."

--
John W. Temples, III

[Keith Thompson]

John Temples <us****@xargs-spam.com> writes:

Keith Thompson wrote:

John Temples <us****@xargs-spam.com> writes:

but that
"evaluatio n" requires an operator.

[...]
Why do you think that evaluation requires an operator?

The C90 standard (to which the compilers I am testing claim to comply)
defines the term "evaluation " in 6.1.5 as "An operator specifies an
operation to be performed (an _evaluation_) [...]" C99 doesn't appear
to have this explicit definition of "evaluation ."

I've found that the standard's definitions, at least the ones defining
a term in italic type, are often incomplete. (See C99's definition of
"lvalue" for an example -- but that particular case has already been
argued to death in comp.std.c.) The more explicit definitions in
section 3 tend to be better. (In my opinion, disclaimer disclaimer,
blah blah.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dan Pop]

In <4v************ *************** *****@4ax.com> Jack Klein <ja*******@spam cop.net> writes:

As for the bit about what constitutes an access to a volatile object
is implementation defined, I agree that the standard has muddied the
water for 15 years and the wording should be expanded to explain the
(claimed) intent.

I strongly suspect that the standard is worded in such a way as to make
"volatile" next to useless (except in the context of signals and longjmp)
for purely political reasons that are far from volatile and so is the
wording in question.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

In <6a************ ********@iswest .net> John Temples <us****@xargs-spam.com> writes:

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects, but that
"evaluation " requires an operator. Does changing the statement to

v + 0;

or

(v);

change this?
No, the expressions are equivalent.
I have some compilers which do and some compilers which do not access
"v" with the above code.

So, avoid it. A much safer approach is:

extern volatile unsigned char v;
void nop(unsigned char);

int main()
{
nop(v);
return 0;
}

For best results, define nop() in a different file. In theory, a super
smart implementation could still optimise away the nop() call, but real
implementations are not that smart...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union