Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site tjalk.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!mcvax!vu44!botter!tjalk!sater
From: sater@tjalk.UUCP (Hans van Staveren)
Newsgroups: net.lang.c
Subject: Re: setjmp: read the manual(long article)
Message-ID: <376@tjalk.UUCP>
Date: Wed, 31-Oct-84 05:00:19 EST
Article-I.D.: tjalk.376
Posted: Wed Oct 31 05:00:19 1984
Date-Received: Fri, 2-Nov-84 04:51:26 EST
References: <363@tjalk.UUCP> <315@idis.UUCP>
Reply-To: sater@tjalk.UUCP (Hans van Staveren)
Organization: VU Informatica, Amsterdam
Lines: 59
Summary: 

>Hans van Staveren wrote:
>
>>	     General solution, all machines, Amsterdam Compiler Kit:
>			...
>>	Well here it is.  Have the  C-frontend  recognize  the  word
>>	setjmp.   In a function containing a call to setjmp save all
>>	registers, use none, and at the end restore  them  all.   At
>>	longjmp  time  just  close  your eyes and jump, no registers
>>	need be restored except the frame pointer, stack pointer and
>>	program  counter.   This  means  that  functions  not  using
>>	setjmp/longjmp are not bothered, in general the compiler can
>>	continue  its  fancy register optimizations and all programs
>>	will run correct.
>
>There is a minor problem with this.
>Since one can have an undefined extern pointer to a function,
>or a pointer to a function passed as an argument,
>one may need to pessimize all calls from some functions
>that do not explicitly call "setjmp".
>Thus contrary to what Hans claimed,
>some functions not using setjmp/longjmp are bothered.
>Presumably these do not occur too frequently in practice.
>Some programs not using setjmp/longjmp are also bothered.
>(I also believe I have heard that the Amsterdam compilers can cheat
>by looking at the source for undefined extern objects,
>although I do not know if it does so in the above instances.)
>
>
>		George Rosenberg
>		duke!mcnc!idis!george
>		decvax!idis!george

Alright, alright!!
I knew when I posted it that someone would see this, but it is one
of the more obnoxious things about our implementation.
Sure, if someone takes the address of setjmp and passes it to another
function which calls it indirectly, our scheme is defeated, or so it
seems. We saw that too.
There are two ways to fix this, the first is to assume all indirect calls
to be dangerous and not use registers, the second and the one we chose
was to check for people taking the address of setjmp, and give them a 
long warning referring to the footnote on page 365a.2 of the manual.
This is ugly, so I didn't post it at first.
However, any programmer that uses functions as dangerous as setjmp
and then hides their calls by indirecting should be banned to
FORTRAN-land for at least ten years.
Before someone else starts screaming about yet another function
that is dangerous in his U*X implementation running up, under or side-by-side
the MAGIC-FOOBAR operating system on the SPEEDY mainframe, it must be
said that the frontend has a list of known dangerous functions compiled
in. At the moment the list is of length 1.

What the cheating comment by George is concerned, I haven't got a clue what
he is talking about.

"If you knew what happened, you would be glad longjmp jumped at all"
-- 
			Hans van Staveren, Vrije Universiteit Amsterdam
			..!{seismo|philabs|decvax}!mcvax!vu44!sater