Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.lang.c
Subject: Re: Ambiguity in definition of setjmp/longjmp makes them much less useful
Message-ID: <660086@hpclscu.HP.COM>
Date: 9 Oct 90 00:14:19 GMT
References: <1597@redsox.bsw.com>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 50

> My real question is this:  Why not define the behavior of setjmp/longjmp so
> that the values of ALL local variables are defined, whether or not they've
> been allocated to registers?  Otherwise, setjmp/longjmp are significantly
> less useful.

Because you want to be able to keep variables in registers. By your
definition, no local variable in a routine that calls setjmp() can ever be
kept in a register beyond a statement boundary. Consider:


    jmp_buf xxx;
    
    foo()
    {
       int i = 0;
       
       if (setjmp(xxx)) {
          i = 5;
	  
	  bar();
       }
    }

    bar()
    {
       longjmp (xxx, 10);
    }

Thus, unless foo() is a leaf routine, you have to assume the worst and keep
"i" in memory.

Most people consider this an unacceptable penalty to pay for what is, at
most, fringe functionality. After all, as you discovered yourself, making
"i" volatile makes it work exactly the way you want it to.

I strongly disagree with the "significantly less useful" part of your
statement above.  Setjmp/longjmp are relatively expensive operations used
to recover from extraordinary situations, and the only sort of guarantees
envisioned by the designers were to:

   - exit the program gracefully, or
   - re-initialize the program to some known initial state.

If you want to implement a general-purpose exception-handling facility, use
"volatile" liberally (or use a C++-like front-end which will do it
automatically for you).
-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar