Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!labrea!decwrl!pyramid!hplabs!cae780!daniels
From: daniels@cae780.TEK.COM (Scott Daniels)
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <4395@cae780.TEK.COM>
Date: Wed, 19-Aug-87 18:21:56 EDT
Article-I.D.: cae780.4395
Posted: Wed Aug 19 18:21:56 1987
Date-Received: Sat, 22-Aug-87 06:05:39 EDT
References: <497@houxs.UUCP> <165600008@uiucdcsb>
Reply-To: daniels@cae780.UUCP (Scott Daniels)
Organization: Tektronix, Inc., CAE Systems DIv., Santa Clara, Ca.
Lines: 96
Summary: Setjmp is magic, users better know it.

In article <165600008@uiucdcsb> kenny@uiucdcsb.cs.uiuc.edu quotes:
>Doug Gwyn, describing Paris conference results (DG>):
>DG>Setjmp must be a macro.

>KK>Does this really translate to ``Setjmp need not exist as a library
>KK>function, but may be implemented in macro form only?'' 
Yes, but for code generation reasons, not just in how its args come.

>DG>I don't have the exact wording that's going into the draft,
>DG>but I think the problem is that the argument to setjmp() is being
>DG>passed by name, which is possible for macros but not for functions.

>Isn't the problem really that setjmp accepts a jmp_buf rather than a
>jmp_buf *?  (Ditto longjmp, ...  perhaps the spec should simply be altered 
>to change the data type...
> we otherwise condemn C programmers to learning all library function 
>parameters are passed by value, oh yes, except for setjmp,...
>Any comments, from either Doug or the peanut gallery?

I am not Doug, so I must be from the peanut gallery.  There is a real problem
wit "setjmp()" as a function: It is the only function that can return more 
than once from an invokation.  
An optimizing compiler must treat setjmp specially in order to keep the
program from behaving in a wierd way (see example below).  If the extremely
conservative assumptions you need to make about setjmp must be made for all
procedure calls, you can kiss almost any optimizations goodbye.  Instead, there
is a requirement that setjmp NOT be a normal procedure, so that people may 
design optimizing compilers that perform the necessary pessimizations around
calls to "setjmp", secure in the fact that the compiler can recognize all such
calls.
The example:

jmp_buf gBlock;

subr() {
 char *state;

 state = "Set up";
 if( setjmp( gBlock ) ) { printf("Stopped during %s\n", state ); return; }
 state = "Initialization";
 initial_processing();
 state = "First Pass";
 pass(1);
 state = "Second Pass";
 pass(2);
 state = "Final Pass";
 pass(3);
 state = "Termination";
 shut_down();
 printf("Wow! we finally succeeded!\n");
}

If the optimizer does not know about setjmp:
 state is a variable which is only read once: in the initial printf.
 The code which can "reach" that use all goes through the statement:
	state = "Set up";
 So, we can replace the state in the printf with "Set up".
 Now, state is a write-only variable, so we can eliminate it.
 The new optimized code is:
subr() {
 if( setjmp( gBlock ) ) { puts("Stopped during Set up" ); return; }
 initial_processing();
 pass(1);
 pass(2);
 pass(3);
 shut_down();
 printf("Wow! we finally succeeded!\n");
}

What the compiler must realize is that any "setjmp" can potentially be 
reached from any procedure call.  This might be done in a number of ways 
inside the compiler, but the key is the compiler must KNOW it is a setjmp.

If you wish to ban the optimizations mentioned above, just imagine the above 
example with the "setjmp(gBlock)" replaced by "ask_if_user_wants_to_proceed()".
I think most everyone would like the above-mentioned optimizatons in that case.

You may also find systems that will not perform correctly if too many or few
arguments are passed to setjmp, since setjmp depends on the stack depth 
at its entrance.  (Note that you cannot write the following procedure, no 
matter how much you might like to:
	my_setjmp( blk ) jmp_block blk; 
	{
	 static int counter = 0;
	 printf("Called setjmp(0x%x) at %d\n", &blk, ++counter );
	 return setjmp(blk);
	}
	#define setjmp my_setjmp
Once my_setjmp exits, the call nevironment saved in blk is invalid.


FROM:   Scott Daniels, Tektronix CAE
	5302 Betsy Ross Drive, Santa Clara, CA  95054
UUCP:   tektronix!teklds!cae780!daniels
	{ihnp4, decvax!decwrl}!amdcad!cae780!daniels 
        {nsc, hplabs, resonex, qubix, leadsv}!cae780!daniels