chris@mimsy.UUCP (Chris Torek) (01/06/89)
In article <184@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes: >I can think of at least one example of a register volatile variable, if >you're playing with setjmp/longjmp. This is the weak spot in my `useless' argument. It would not come up if X3J11 had not done such a horrid thing with setjmp/longjmp; and remember that I was arguing from an `if things were slightly different' viewpoint. (If things were different, they would be different, so there is not too much reason to keep arguing. But things could be slightly different and still consistent----which is all I ever meant to say!) >"Register volatile x" tells the compiler to try and store it somewhere >quick, but safe from setjmp/longjmp. In most compilers, this would >basically turn off the register declaration, but in transputer compilers >I've used, "register" tells the compiler to keep the value in the 16 words >nearest the stack pointer, which are especially quick to access. Here, >register and volatile both mean something. > >Can anyone poke holes in this example? (Aside from the `if (y = 0)' that should have been `if (y == 0)' :-) ) For portable code, you must avoid `register volatile', because current systems (not dpANS-conformant, but still useful, such as SunOS) will use something like #define volatile /*empty*/ and will see register /*empty*/ int x; and will do what I described earlier (restore x to the value it had at the call to setjmp()), whereas if you write volatile int x; the compiler will see /*empty*/ int x; and will do the `right thing'. If you are not interested in running under pre-ANSI compilers, you may ignore this argument. (But calls to setjmp() are rare enough that I, for one, intend never to use any register variables around setjmp().) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/06/89)
In article <15304@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > For portable code, you must avoid `register volatile', because current > systems (not dpANS-conformant, but still useful, such as SunOS) will > use something like > #define volatile /*empty*/ But that's clearly wrong in the first place. When back-porting to a pre-ANSI C environment, all uses of "volatile" (there shouldn't be many) have to be carefully checked to determine just why "volatile" was necessary, and adjustments made (if possible). There is no viable alternative! P.S. I do plant the above definition in pre-ANSI C environments (although I can't recall using it), but I don't expect it to "do the right thing" automatically, because it can't.