Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!decvax!genrad!grkermi!panda!talcott!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA
Newsgroups: net.unix-wizards
Subject: Re: Bug iwith setjmp/longjmp on Vax
Message-ID: <11255@brl-tgr.ARPA>
Date: Sat, 8-Jun-85 00:10:03 EDT
Article-I.D.: brl-tgr.11255
Posted: Sat Jun  8 00:10:03 1985
Date-Received: Tue, 11-Jun-85 03:42:39 EDT
References: <44700008@gypsy.UUCP>
Organization: Ballistic Research Lab
Lines: 21

> main(){
> 	foo();
> 	longjmp(env, 1);
> }
> 
> foo(){
> 
>   mode = setjmp(env);
>   if (mode != 0) magic();
> }

"If longjmp is called even though env was never primed by a call to
setjmp, or when the last such call was in a function which has since
returned, absolute chaos is guaranteed."
	- System V Interface Definition

You see, foo()'s stack frame has been totally trashed after he
returned (e.g., arguments to longjmp were pushed onto the stack
at addresses that were formerly part of foo()'s stack frame), and
when the longjmp attempts to reactivate it it no longer makes any
sense..  Sometimes it may work by accident, but it WILL be an accident.