Path: utzoo!mnetor!uunet!husc6!mailrus!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.lang.c
Subject: Re: volatile
Message-ID: <1988Mar30.110820.23882@light.uucp>
Date: 30 Mar 88 19:08:16 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <1878@rtech.UUCP> <1988Mar29.162711.12610@utzoo.uucp>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Light Systems, Mountain View, CA
Lines: 33
Summary: volatile is needed

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