Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!hao!cires!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.lang.c Subject: Re: setjmp: read the manual Message-ID: <914@opus.UUCP> Date: Fri, 19-Oct-84 03:40:15 EDT Article-I.D.: opus.914 Posted: Fri Oct 19 03:40:15 1984 Date-Received: Sun, 21-Oct-84 14:44:54 EDT References: <1045@research.UUCP> <1735@sun.uucp> Organization: NBI,Inc, Boulder CO Lines: 29 Regarding the setjmp/longjmp interaction with register variables... dmr gave one approach and justified it on the basis of "correct" behavior. A response... > There's a good reason for doing it the other way: efficiency... Did I really miss something, or did someone just tell us that it is reasonable to compromise correctness for efficiency? I have a tough time with such compromises. >... > We looked hard at this and decided to change the meaning of > setjmp/longjmp (to the above) rather than having EVERY function save... The parent article goes on to describe problems with saving all the registers on a 68000. In fact, there is a "whizzo" (his words) instruction on the 68000 to save whatever set of registers you need, and you clearly won't need to save all of them. >... > To fix a program that this breaks, you remove "register" declarations from > routines that call setjmp. Not so bad. Actually, the task of fixing a program that breaks is a little harder: First you have to realize that the problem is a setjmp/register interaction. Realistically, that might take days to find (particularly if you're porting someone else's code). I can't call that "not so bad". -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Lately it occurs to me what a long, strange trip it's been.