Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!johnl
From: johnl@godot.UUCP
Newsgroups: net.lang.c
Subject: Re: setjmp/longjmp
Message-ID: <432@ima.UUCP>
Date: Wed, 31-Oct-84 23:37:10 EST
Article-I.D.: ima.432
Posted: Wed Oct 31 23:37:10 1984
Date-Received: Fri, 2-Nov-84 05:07:55 EST
Lines: 28
Nf-ID: #R:decwrl:-399400:ima:10100002:000:1680
Nf-From: ima!johnl    Oct 31 09:40:00 1984

Doug Gwyn argues that longjmp() should always restore all variables in the 
calling routine, and that on machines where this is impossible (because you 
can't tell how many registers were saved at each call) the calling sequence 
"should be fixed." 

No dice.  On machines without stack hardware, such as most notably the IBM 370 
series, it's hard enough to set up a fast C calling sequence without adding 
extra restrictions on unwindability.  When designing VM/IX (the version of Unix 
that runs under VM/370) it took them months to get a calling sequence that 
worked and was only a few instructions.  Changing it so that longjmp() could 
unwind it would add several instructions to every call and return, or else 
require storing and loading many registers which don't change, a similar 
penalty.  This seems a lot to pay for an occasional call to longjmp().  Sounds 
to me much like the traditional bad habit in much Berkeley software of assuming 
that you can dereference a zero pointer and find a zero there -- again much 
hardware makes this difficult or impossible, and in that case I believe we all 
agree that programs that depend on such behavior aren't portable.  

There seems to be a consensus that the semantics for longjmp() should promise 
that all variables in the calling routine except those declared to be 
"register" are restored after a longjmp(), which is both easy to understand and 
straightforward to implement on all hardware of which I am aware.  It also 
happens to be the de-facto standard now, so claims that programs "can't work" 
if longjmp() behaves that way are hard to believe.  

Incendiarily, 

John Levine, ima!johnl or Levine@YALE.ARPA