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.