mb> Huh? the values are indeterminate, not those at the time of mb> the longjmp. Read what I wrote about the "existing code is completely wrong"; I was under the completely mistaken impression that setjmp salted away the "environment" _including values_ so that execution state could be reset _exactly as it was_ when setjmp was called. In fact "environment" doesn't include variable values, and the jmp_buf (AFAICT from setjmp.h under Linux/glibc 2.3.1) simply allows you to recover the stack frame. mb> The semantics of those macros is getting trickier and mb> trickier. mb> What happens in future maintenance if someone modifies one of mb> those variables declared VOLATILE_IF_NEEDED_TO_SHUT_UP_GCC? They look up the definition of VOLATILE_IF_NEEDED_TO_SHUT_UP_GCC, which should have an explanatory comment that this is purely warning suppression. Much worse is the situation in unix_open_network_stream where you have (currently in 21.4) RETURN_TYPE unix_open_network_stream (ARGUMENTS) { int inch; volatile int s; if (SOME_TEST) invalid_argument (); /* does not return */ else { if (setjmp ()) { s = socket (); } else { s = socket (); } } inch = f (s); } Now the "volatile" not only inhibits the bitching about longjmp, but also the bitching about s being uninitialized in the last line. GCC is smart enough to figure out that invalid_argument doesn't return, so under GCC this (correct) code issues no warnings. But if you do maintenance on this kind of complex logic, you don't want the warnings disabled! mb> I'm not sure why I care, but I did some testing, and it mb> suggests that whether the warning is issued has nothing to do mb> with C++ vs. C, but only the compiler versions and compilation mb> options. You're right. I thought that 2.95.4 did not issue warnings, but it turns out that the buttheads at Debian changed the default gcc from 2.95 to 3.2 last week without mentioning it in the upgrade. (Cf. the popup messages that Jason Mastaler's TMDA generates; it tells you not only that you should read UPGRADE.gz, but any real showstoppers.) mb> Since the warning _is_ issued by g++ 2.95, VOLATILE_IF_NOT_CPP mb> makes no sense. OK. Boy was I lucky -- I put it "TO_SHUT_UP_GCC" to make a different point.:-) mb> Zack Weinberg says: mb> The compiler generates those warnings for just about every mb> variable in a function that calls setjmp or vfork. mb> you may be able to structure your code like this: jmp_buf env; int main(void) { if(setjmp(env)) { cleanup(); return 1; } do_all_the_real_work(); return 0; } mb> - the key being to have no actual code in the routine that mb> calls setjmp, just function calls. mrrmf. See my other post; AFAICT we can't cleanly initialize old_sigpipe outside of the code controlled by setjmp. The standard doesn't even allow this: longjmp_p = setjmp (jmpbuf); if (longjmp_p) { /* clean up */ } else { old_sigpipe = signal (SIGPIPE, send_process_trap); /* do I/O */ signal (SIGPIPE, old_sigpipe); } -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.