This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/21035] longjmp() resets FPU exception mask
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 12 Jan 2017 15:57:14 +0000
- Subject: [Bug math/21035] longjmp() resets FPU exception mask
- Auto-submitted: auto-generated
- References: <bug-21035-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21035
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The floating-point state is logically like a thread-local variable.
Indeed, on some platforms some parts of it *are* TLS variables.
It would be wrong for siglongjmp to restore the value of a thread-local
variable to what it was when sigsetjmp was called - the user program might
have changed it after calling sigsetjmp, and that change must remain in
effect. Likewise, it would be wrong for siglongjmp to restore the
floating-point environment to what it was when sigsetjmp was called -
changes made by the user program must remain in effect. You want the
state as it was before the kernel called the signal handler, but
siglongjmp doesn't have access to that information.
Note that POSIX explicitly says about longjmp (and the siglongjmp
differences don't matter): "All accessible objects have values, and all
other components of the abstract machine have state (for example,
floating-point status flags and open files), as of the time longjmp() was
called, except that the values of objects of automatic storage duration
are unspecified if they meet all the following conditions".
--
You are receiving this mail because:
You are on the CC list for the bug.