Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!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 Summary: how about setjmp/longjmp? slightly off track... Message-ID: <8356@bloom-beacon.MIT.EDU> Date: 7 Dec 88 23:28:55 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> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: raeburn@athena.mit.edu (Ken Raeburn) Organization: Massachusetts Institute of Technology Lines: 42 In article <1988Dec6.180614.23949@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I think you have to consider volatile as meaning "no surprises" -- is >it really a surprise that a large unaligned object requires more than one >access? This sounds a lot more reasonable.... Chris Torek's article got me thinking. On a machine that can't do single-byte accesses, device-driver routines shouldn't have volatile char structure components. It wouldn't make sense. (Getting slightly off the subject here....) 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?) (Hope this hasn't gone by in discussions already... I only read news off-and-on....) 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? Actually, my own interest in the uses of "volatile" is more in the line of device drivers... Real Soon Now I should get around to trying to build some of the BSD drivers with gcc, really I will... I was just wondering about this point. _kr