home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!asuvax!chnews!sedona!bhoughto
- From: bhoughto@sedona.intel.com (Blair P. Houghton)
- Newsgroups: comp.unix.internals
- Subject: Re: Question about longjmp ()
- Date: 10 Jan 1993 23:05:17 GMT
- Organization: Intel Corp., Chandler, Arizona
- Lines: 25
- Message-ID: <1iqa3dINNb96@chnews.intel.com>
- References: <C0JpMo.1rGr@austin.ibm.com> <1993Jan10.145640.3647@sequent.com> <184875@pyramid.pyramid.com>
- NNTP-Posting-Host: stealth.intel.com
-
- In article <184875@pyramid.pyramid.com> jmuth@pyrps5.eng.pyramid.com (John Muth) writes:
- >I'm not sure what the C langauge spec. says about the semantics of this sort
- >of construct or even if it addresses it at all. After all, K&R left lots of
- >things like this up to the imagination of the complier writer.
-
- The standard (ANSI X3.159-1989) says, after much waving of
- hands and servicing of lips, that the value of `i' in this
- program is "indeterminate" after the call to longjmp (because
- it's an auto variable changed between the calls etc. etc.).
-
- >My suggestion to the original poster is "don't do that". Setjmp defines
- >a return value in order to avoid this situation. Use it.
-
- Um, yes, theoretically you can save `i' by passing it back
- through longjmp, but you only get to do that to one
- variable.
-
- The real value of setjmp/longjmp is that it restores the
- signal mask and can pull you out of a deep recursion if a
- minor occurrence results in a rare and complicated
- problem. You shouldn't use it as part of handling
- predictable errors; then it'd be just another `goto'.
-
- --Blair
- "etc., etc..."
-