Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: *devaddr = 0 and volatile Message-ID: <9107@smoke.BRL.MIL> Date: 8 Dec 88 16:55:50 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> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 45 In article <8356@bloom-beacon.MIT.EDU> raeburn@athena.mit.edu (Ken Raeburn) writes: >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?) I don't understand what the problem is. Upon a longjmp()ed return from a matching setjmp(), all accessible objects have values as of the time longjmp() was called, except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp() macro that do not have volatile-qualified type and have been changed between the setjmp() invocation and longjmp() call are indeterminate. [From the proposed standard.] The only mention of "volatile" is that a volatile auto is guaranteed to have the correct value, even though a non-volatile auto in the same function may have been cached and therefore have an incorrect stored value. (Otherwise, optimizers would have to give special treatment to use of setjmp/longjmp.) "volatile" really has nothing to do with setjmp/longjmp semantics; the explicit note that its use could make a local auto safe even across longjmp() was just weakening the exception being made for local autos due to the effects of optimization, since it was clear that "volatile" semantics permitted this extra guarantee. >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? The compiler can allocate extra storage in many cases, but it's not necessary here. Use of "volatile" does not give the compiler license to fail to translate a conforming program. Warnings can be issued any time the implementor wishes.