Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!sm.unisys.com!csun!polyslo!cquenel
From: cquenel@polyslo.CalPoly.EDU (93 more school days)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <7392@polyslo.CalPoly.EDU>
Date: 26 Jan 89 19:34:51 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <7283@polyslo.CalPoly.EDU> <15626@mimsy.UUCP>
Reply-To: cquenel@polyslo.CalPoly.EDU (93 more school days)
Organization: Blue Blaze Irregulars
Lines: 28

In article <15626@mimsy.UUCP> chris@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