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