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