On 10/5/06, Ricard Wanderlof <ricard.wanderlof@xxxxxxxx> wrote:> You may be right. Reading standards is hairy and I would also consider the> interpretation "evaluate the expression and discard the value" valid.> Although I'm nitpicking here, say if foo were a hardware register which> had a side effect of some sorts when reading it, then the statement *foo;> would actually do something even though the value wouldn't be used (better> declare foo volatile too to make sure the compiler doesn't optimize it> away).Yes, you are right! If you declare foo to be volatile, indeed itsvalue is must be read.
In any case, I wouldn't like to let a line like>> *( (char *) 0);In this case we only need to write this as:
*( (volatile char *) 0);
But unlike the value, the address is not volatile. It's not a variable. So,
&(*( (volatile char *) 0));
will still have no side effect. Only the char is volatile, not theaddress, right? So,
s->foo; // fetches the value of foo(ideally)
&(s->foo); // will not fetch the value of foo - only compute itsaddress - since, computing the address of foo (here, by reading thevariable s) has no operation over the value of foo. So, thisexpression must have side effect only upon 's', if there ever is any.
pass by the compiler, whether or not the actual compiler conforms to the> standard, whichever the interpretation of the standard may be. It's one of> the situations that I would imagine a compiler designer could get wrong,> regardless what the standard says...
In support of your point,
======Page 108========
An object that has volatile-qualified type may be modified in waysunknown to the implementation or have other unknown side effects.Therefore any expression referring to such an object shall beevaluated strictly according to the rules of the abstract machine, asdescribed in 5.1.2.3....What constitutes an access to an object that has volatile-qualifiedtype is implementation-defined.
======end=========
According to section 5.1.2.3
========Page 13============
Accessing a volatile object, modifying an object, modifying a file, orcalling a function that does any of those operations are all sideeffects, which are changes in the state of the execution environment.Evaluation of an expression may produce side effects. At certainspecified points in the execution sequence called sequence points, allside effects of previous evaluations shall be complete and no sideeffects of subsequent evaluations shall have taken place....
In the abstract machine, all expressions are evaluated as specified bythe semantics. An actual implementation need not evaluate part of anexpression if it can deduce that its value is not used and that noneeded side effects are produced (including any caused by calling afunction or accessing a volatile object).
========end==========
So I believe that in a recommended implementation,
a;
must fetch the value of 'a', though it should be discarded. But thenthe compiler in our case optimises it (by not reading 'a'), unless 'a'is declared as 'volatile'.
Thank you for pointing out this really nice one.
Regards,Jinesh.��������!���W��v������ޗ��{��f���� ��ޖw�n'�������Y�����
