Damn it, now you've got me doing it.
Copy of post inadvertantly addressed to xemacs-review.
Ben, please reply to this one.
>>>> "mb" == Martin Buchholz
>>>> "sjt" == Stephen J Turnbull
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
188.8.131.52 [#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. So I see
nothing wrong with VOLATILE_IF_NEEDED_TO_SHUT_UP_GCC, since the only
point is to shut up GCC.
(Or replace .txt with .pdf for a printable form. Same size.)
 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.