🚀 go-pugleaf

In article <46p60k$nbu@newshost.lanl.gov>,
Tanmoy Bhattacharya <tanmoy@qcd.lanl.gov> wrote:
>In article <814744121snz@wbriscoe.demon.co.uk>, walter briscoe
><walter@wbriscoe.demon.co.uk> writes: 
>|> In article <814632687snz@soliton.demon.co.uk>
>|>            ian@soliton.demon.co.uk "Ian Cargill" writes:
>|> 
>|> > The restrictions on where setjmp can be placed seem fairly 
>|> > logical - for reasons outlined in the Rationale.  But...
>|> > One construct that is not allowed is 
>|> > 
>|> > a = setjmp(buf);
>|> > if(a)
>|> >  . . .
>|> > 
>|> > Any particular reason why this might not be allowed?  I wouldn't 
>|> > have thought it was a problem with temporaries.  
>|> 
>|> Can't answer the question. However, this construct used to fail in DEC's
>|> VAX C 3.x.
>
>It seems to me that the restrictions in the standard are such that longjmp
>can be implemented as a jumptable at compile time. `a = setjmp(buf)' cannot
>be.

That seems plausible, but I know of no reason why it should need to be
implemented that way.  The rules on local variables are quite sufficient
to implement setjmp() efficiently in any context that a real function
invokation is legal.  In fact, one of the easiest implementations of it
is to call a real assembler function that unpicks the stack and saves
the relevant registers.

I believe that the REAL reason for the restriction is that certain nasty
implementations (probably on IBM PCs) had that limit, and the relevant
vendors got X3J11 to document the imbecilities of their implementations.
This certainly happened in some other areas.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679