Behaviour of setjmp/longjmp and registers
93 more school days
cquenel at polyslo.CalPoly.EDU
Fri Jan 27 05:34:51 AEST 1989
In article <15626 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>
>Now, clearly one can sprinkle `volatile' qualifiers into the
>declarations in timed_fiddle_with(), so that it will work under pANS
>C. But (at least some of) the variables so declared are not in fact
>volatile---the value of `base', in particular, *never changes!* The
>qualifier is being (mis)used strictly for its side effect of inhibiting
>optimisation, not because the variable that is so qualified behaves in
>a way that is not described by the virtual machine.
This depends on how you look at it.
If you think of "volatile" as meaning "this has to live in memory",
then it makes sense to me.
Or if you consider that the setjmp/longjmp mechanism
in a very real sense DOES violate the "virtual machine",
then volatile is a very appropriate description.
Some people seem to think that ideally, setjmp/longjmp
should take the program back in TIME. I think that
*conceptually* longjmp should only take the program back
to a previous execution point. A C routine (IMHO) has only
one existence. If a routine runs through part A and then
setjmps and then runs through part B and then longjmps.
I would *expect* that it's state would be the state after
the execution of part B. That is the way my working defenition
of the "C" virtual machine works.
--chris
More information about the Comp.lang.c
mailing list