*devaddr = 0 and volatile

[Ken Raeburn]

In article <1988Dec6.180614.23949 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>I think you have to consider volatile as meaning "no surprises" -- is
>it really a surprise that a large unaligned object requires more than one
>access?

This sounds a lot more reasonable....

Chris Torek's article got me thinking.  On a machine that can't do
single-byte accesses, device-driver routines shouldn't have volatile
char structure components.  It wouldn't make sense.

(Getting slightly off the subject here....)

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?)

(Hope this hasn't gone by in discussions already... I only read news
off-and-on....)

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?

Actually, my own interest in the uses of "volatile" is more in the
line of device drivers... Real Soon Now I should get around to trying
to build some of the BSD drivers with gcc, really I will... I was just
wondering about this point.

_kr