[Originally, we had code equivalent to the following:
int *foo(void) { int i; return &i; }
int main(void) { foo(); return 0; }
I myself do not know whether this code is well-defined. We can
say for sure that "i" does exist at the point of the "return"
statement that takes its address, and no longer exists by the
time foo() has returned to main(), so the "value" returned by
the function has undefined behavior if it is used -- but it is
not "used".]
So the result of an expression-statement must not be read if it is a
function call, and must be read if it is a variable (and all exceptions
are results of the as-if rule)? Where does the standard make this
distinction?
This is an interesting point. Here is Program P:
extern volatile int hardware_reg;
int main(void) {
volatile int *p = &hardware_reg;
*p; /* or, equivalently, "hardware_reg;" (without quotes) */
return 0;
}
When run (after compiling with special Linker Magic to make the
external variable "hardware_reg" correspond to a hardware register
on the system), this program clears the register -- it is one of
those "self-clearing upon read" registers -- and is thus useful
after some particular kinds of errors. (Perhaps the error it clears
has to do with the audio subsystem, so it makes the sound work on
the machine again.)
Now we modify Program P a bit, giving Program Q:
extern volatile int hardware_reg;
volatile int *f(void) { return &hardware_reg; }
int main(void) { *f(); return 0; }
This obviously does the same as Program P. But note that we used
the unary "*" operator in main(). If we had done that with the
original program, now modified to become Program R:
int *foo(void) { int i; return &i; }
int main(void) { *foo(); return 0; }
we would definitely (I believe) have undefined behavior. So now
we might write Program S:
volatile int *foo(void) { int i; return &i; }
int main(void) { foo(); return 0; }
The key seems, in this case, to be the unary "*" operator. It
is OK to skip "reading" the value returned by some function,
even if it is a "pointer to volatile", as long as we do not
actually follow the pointer.
If a function could return a volatile-qualified type (and it cannot),
and if the volatile-qualified type were a C++-like reference (which
C lacks), we could rewrite one of the above to produce Program T:
volatile int &f(void) { return hardware_reg; }
int main(void) { f(); return 0; }
In this case the actual read of the hardware register would occur
(logically at least) in main(), rather than in f(), giving rise to
the potential conflict that Harald is asking about. Fortunately,
we cannot express the problem in C in the first place.
