Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!husc6!wjh12!redsox!campbell From: campbell@redsox.bsw.com (Larry Campbell) Newsgroups: comp.lang.c Subject: Ambiguity in definition of setjmp/longjmp makes them much less useful Message-ID: <1597@redsox.bsw.com> Date: 7 Oct 90 17:47:34 GMT Reply-To: campbell@redsox.bsw.com (Larry Campbell) Organization: The Boston Software Works, Inc. Lines: 46 We have implemented a portable (or so we thought) exception handling facility for C. In order to allow exception handlers to have the same scope as the code being guarded, we used setjmp/longjmp instead of ssignal. However, the ambiguous definition of setjmp/longjmp is giving us heartburn. Consider the following code: ---------------------------------------- 1 { 2 int x; 3 x = 0; 4 if (! setjmp(foo)) 5 { 6 x = 1; 7 foo(); 8 } 9 else 10 { 11 printf(x = %d\n", x); 12 } 13 } ---------------------------------------- If foo() calls longjmp, the value of x when line 11 gets executed appears to be undefined (I don't have a copy of the ANSI standard, but I've checked about eight compiler manuals; most say it's undefined, or undefined if x isn't declared volatile). In the three compilers I've tested that claim ANSI compliance, declaring x to be volatile yields the desired result (x = 1). In the non-ANSI compilers, disabling optimization yields the desired result, but enabling optimization usually yields x = 0. I've never seen any value for x other than 0 or 1. 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. For what it's worth, it seems to me that the description of setjmp/longjmp in K&R 2 does imply that x should have the value 1; is this an area of disagreement between K&R and ANSI? -- Larry Campbell The Boston Software Works, Inc. campbell@redsox.bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02109