volatile

[Bakul Shah]

You must be able to tell a compiler that certain variables have side
effects *IF* you are using a highly optimizing compiler and you do one or
more of the following:

    o   access a global variable from a signal handler
    o   access a shared variable
    o   patch a variable in the executable file
    o   implement co-routines
    o   access a memory mapped io address
    o   access a variable from procedures written in two different languages

An application program, written in ``pure'' C (that is, it does not use
shared memory, uses either routines written in C or standard routines, does
not use signal handling, does not need didling with executables, does not
have co-routines/lighweight processes, does not use setjmp/longjmp) does
not need volatile and can safely ignore it.

But if you write a program that does do any of the above strange things,
`volatile' is a *portable* way of telling the compiler about side effects.

If a compiler wishes to ``ignore'' volatile, it must treat all non-register
variables as implicitly volatile.

Since you don't know what kind of compiler is available on another machine,
I claim use of volatile will actually promote portability for your IO
drivers, co-routines, customizable applications, shared memory using
programs, non-trivial signal handlers, operating systems, etc.  Granted,
you don't get complete portability but code needing change will be lot less
and need less work.
-- 
Bakul Shah

..!{ucbvax,sun}!amdcad!light!bvs