Vladimir Ushakov added the comment: SIGBUS as well as SIGFPE or SIGSEGV is a synchronous signal. It is delivered to the thread that caused the trouble and the stack contents is well defined.
> https://www.securecoding.cert.org/confluence/display/seccode/SIG35-C.+Do+not+return+from+SIGSEGV,+SIGILL,+or+SIGFPE+signal+handlers Does not apply here: longjmp is not a return. > https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler The grounds are weak. They refer to SIG30-C, which is based on ISO C standard. POSIX explicitly declares the fact that longjmp is allowed to exit signal handlers as an extension to ISO C standard. (See http://pubs.opengroup.org/onlinepubs/9699919799/) Besides, POSIX explicitly states that only async-signal-safe functions can be called from the handlers, which "are invoked asynchronously with process execution". That's not out case as mentioned above, we are not in asynchronous context as it could be with, say, SIGINT. (See http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html) Glibc doesn't mind as well: http://www.gnu.org/software/libc/manual/html_node/Longjmp-in-Handler.html I can doubt about non-POSIX platforms, but with POSIX everything seems clean to me. Especially since the method is already in use with SIGFPE. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16212> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
