*devaddr = 0 and volatile

[Doug Gwyn]

In article <8356 at bloom-beacon.MIT.EDU> raeburn at athena.mit.edu (Ken Raeburn) writes:
>But what about variables (automatic, global, or static) that are used
>in the neighborhood of setjmp/longjmp calls?  If I have a variable
>that is a char or small enum (which my compiler might want to fit into
>a char under normal circumstances), what happens when I declare them
>volatile?  I think that, given sufficiently bizzarre machine
>descriptions, possibly any type (except maybe int?) might require
>multiple accesses (multiple reads, or reads-and-writes) for at least
>some machine types.  The "no-surprise" guideline seems like the only
>way to make sense of this across different machine types.  (My
>impression is that the use of "volatile" for setjmp/longjmp is covered
>under "portability" rather than "machine-specific device drivers", and
>I should be able to do something reasonable here in a portable way.
>Or should I?)

I don't understand what the problem is.

Upon a longjmp()ed return from a matching setjmp(), all accessible
objects have values as of the time longjmp() was called, except that
the values of objects of automatic storage duration that are local
to the function containing the invocation of the corresponding
setjmp() macro that do not have volatile-qualified type and have
been changed between the setjmp() invocation and longjmp() call are
indeterminate.  [From the proposed standard.]

The only mention of "volatile" is that a volatile auto is guaranteed
to have the correct value, even though a non-volatile auto in the same
function may have been cached and therefore have an incorrect stored
value.  (Otherwise, optimizers would have to give special treatment to
use of setjmp/longjmp.)  "volatile" really has nothing to do with
setjmp/longjmp semantics; the explicit note that its use could make a
local auto safe even across longjmp() was just weakening the exception
being made for local autos due to the effects of optimization, since
it was clear that "volatile" semantics permitted this extra guarantee.

>Can the compiler allocate extra storage around a "volatile" variable
>(that is not part of a structure and does not have external linkage)
>and randomly smash it when this variable needs to be accessed?  Or is
>it valid to just have it complain that this particular machine type
>can't do that particular operation?

The compiler can allocate extra storage in many cases, but it's not
necessary here.  Use of "volatile" does not give the compiler license
to fail to translate a conforming program.  Warnings can be issued
any time the implementor wishes.