Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.lang.c
Subject: Re: *devaddr = 0 and volatile
Message-ID: <8490@bloom-beacon.MIT.EDU>
Date: 17 Dec 88 06:49:20 GMT
References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <13784@oberon.USC.EDU> <14832@mimsy.UUCP> <9059@smoke.BRL.MIL> <21686@apple.Apple.COM> <23706@amdcad.AMD.COM> <1988Dec6.180614.23949@utzoo.uucp> <8356@bloom-beacon.MIT.EDU> <9107@smoke.BRL.MIL>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: raeburn@athena.mit.edu (Ken Raeburn)
Organization: Massachusetts Institute of Technology
Lines: 20

>I don't understand what the problem is.

My problem was with the idea being discussed that references to a
volatile variable translate to exactly one memory reference.  On a
machine that may require more than one memory access to retrieve or
store one of the C data types (especially if you deal with entire
structures at a time) this wouldn't work.

Being more awake this time, I would point out that any piece of
machine-independent, portable code could have "volatile" declarations
added without ill effect (except perhaps some loss of optimization);
my references to setjmp/longjmp were just reaching for some case
outside of device drivers and the like where use of "volatile" would
be useful, but that's beside my point.  Since any type could have the
"volatile" qualifier, the one-access stuff is out the window.

I was basically trying to find out something that somebody posted a
short while later, which I hadn't noticed before in the draft
standard: "What constitutes an access to an object that has
volatile-qualified type is implementation-defined."