Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!godot!ima!ism780!darryl
From: darryl@ism780.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: setjmp: read the manual
Message-ID: <402@ism780.UUCP>
Date: Wed, 17-Oct-84 00:19:20 EDT
Article-I.D.: ism780.402
Posted: Wed Oct 17 00:19:20 1984
Date-Received: Thu, 18-Oct-84 06:57:44 EDT
Lines: 0
Nf-ID: #R:sun:-173500:ism780:12500014:000:1358
Nf-From: ism780!darryl    Oct 16 09:23:00 1984

>> V7, 4.[01]BSD, and SVr0 manuals include this sentence in the setjmp/longjmp
>> documentation (setjmp(3): "All accessible data have values as of the time
>> longjmp was called."  ...  (This is nontrivial, because the
>> place where the register that contained x was saved can be anywhere in
>> call chain.)
>>
>> There is a very good reason for doing it this way: it makes
>> register and automatic variables behave the same.
>>
>There's a good reason for doing it the other way: efficiency.  The Sun
>(4.2 on 68010's) setjmp(3) says:
>
>       "All memory-bound data have values as of the time longjmp was called.
>        The machine registers are restored to the values they had at the time
>        setjmp was called.  But, because the register storage class is
>        only a hint to the C compiler, variables declared as register
>        variables may not necessarily be assigned to machine registers,
>        so their values are unpredictable after a longjmp.  This is
>        especially a problem for programmers trying to write machine-
>        independent C routines."

Gee, wouldn't it be easier to just make your jmp_buf big enough to hold all
of the registerable registers and save them at setjmp time and restore them
at longjmp?  Then they would retain their values as of setjmp...

	    --Darryl Richman
	    ...!cca!ima!ism780!darryl