Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!gymble!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.lang.c
Subject: Volatile type in ANSI C
Message-ID: <543@lll-crg.ARPA>
Date: Wed, 24-Apr-85 15:51:09 EST
Article-I.D.: lll-crg.543
Posted: Wed Apr 24 15:51:09 1985
Date-Received: Fri, 26-Apr-85 22:58:38 EST
Distribution: net
Organization: Lawrence Livermore Labs, CRG group
Lines: 26

Looking at the description for the volatile type in the draft of the
ANSI C standard there seems to be some incompleteness.
The volatile type could have uses in multiprocessing where several
processors share some data areas.  One could have volatile pointers to
non volatile data areas (rarely) and more frequently nonvolatile pointers
to volatile data areas that are shared with other processors.
Does the ANSI C standard address these issues?

One certainly ought to have a non volatile pointer to a volatile storage
area.  The declaration

register volatile int *pint;

is a good example.  A register pointer, which can't possibly be volatile,
is used to point to a volatile storage area.  On each access to the pointed
to int one wants to actually do the memory operation and not allow cacheing
of the integer value in another machine register.

One would certainly have uses for the above when multiprocessing.  The
the other case, a volatile pointer to a non volatile int, does not have
any utility that is clear to me but who knows when someone might find a use
for one.

If ANSI C is going to add a new type to the language defintion shouldn't
we carfully consider all the applications of it and make sure the addition
to the language will take care of all the possible uses?