Damn it, now you've got me doing it. Copy of post inadvertantly addressed to xemacs-review. Ben, please reply to this one. sjt> It seems to me that this code (simplified from sjt> process-unix.c) is just plain wrong: OK, I was wrong about this, at least Linux does what draft ISO C99[1] 7.13.2.1 [#3] says it should do, namely use the values at the time of the longjmp (not the values at the time of the setjmp; I wish the man pages and the standard would be more precise; "restores the environment" sounds like "restores the values and other stuff" to me). mb> Note that there are never issues with gcc's generated code, mb> since gcc will always do the safe thing, as if the variables mb> were declared volatile. [...] Note: those volatile's were mb> added initially to shut up gcc (as well as, of course, to have mb> safe code). Of course. But AFAICT the code is safe without volatile.[2] So I see nothing wrong with VOLATILE_IF_NEEDED_TO_SHUT_UP_GCC, since the only point is to shut up GCC. Footnotes: [1] http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt. (Or replace .txt with .pdf for a printable form. Same size.) [2] Unless there's a race condition during the assignment of the value of signal() to old_sigpipe. But the volatile qualifier doesn't protect you from being hosed by such a race condition. -- 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.