site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: University of Michigan User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 On May 28, 2005, Matt Watson wrote:
On May 28, 2005, at 7:47 PM, David N. Williams wrote:
Is the Tiger behavior a bug? If so, I'll file a bug report. Please let me know what you think.
This is not a bug. longjmp() should restore the environment at the time of the setjmp() and floating-point rounding mode is part of the environment, so Tiger does this correctly. I'm going to argue below that it's not so clear that the rounding mode is part of the environment for this purpose, basically because the spec for setjmp() is silent about that. As to the "for example, floating-point status flags" part of the man page, floating-point status flags are not floating-point control modes. See the distinction here:
http://www.opengroup.org/onlinepubs/009695399/basedefs/fenv.h.html
[...]
A floating-point status flag is a system variable whose value is set (but never cleared) when a floating-point exception is raised, which occurs as a side effect of exceptional floating-point arithmetic to provide auxiliary information. A floating-point control mode is a system variable whose value may be set by the user to affect the subsequent behavior of floating-point arithmetic. I much appreciate your going to the trouble to locate this reference. But your conclusion that longjmp() should restore the rounding mode part of the floating-point environment doesn't seem that obvious to me. While it doesn't say anything explicit about setjmp/longjmp, it seems to me that the spirit of what it does say would allow the programmer to change the rounding mode between the two. It says: Certain application programming conventions support the intended model of use for the floating-point environment: * A function call does not alter its caller's floating-point control modes, clear its caller's floating-point status flags, nor depend on the state of its caller's floating-point status flags unless the function is so documented. * A function call is assumed to require default floating-point control modes, unless its documentation promises otherwise. * A function call is assumed to have the potential for raising floating-point exceptions, unless its documentation promises otherwise. With these conventions, an application can safely assume default floating-point control modes (or be unaware of them). The responsibilities associated with accessing the floating-point environment fall on the application that does so explicitly. So for ordinary function calls, the programmer is allowed to change the mode between functions as long as he documents it; and I don't see anything that should be interpreted as disallowing that between setjmp() and longjmp(). Moreover, couldn't the fact that the two are typically embedded in different functions be taken as an argument that they *should* be treated that way? The spec for longjmp/setjmp also doesn't say that any part of the floating point environment except for status flags should be restored. It says "for example" floating-point status flags should not be restored; and indeed, the floating point control modes seem to me sort of analogous to file open/close modes, and might even be seen in the spirit of "accessible objects" (except I was unable to find the definition of those in Single Unix 3). I am really not an expert on this kind of thing; but it seems to me that the meaning of the "environment saved" by setjmp() which longjmp() is supposed to restore, which I take to be the contents of jmp_buf, is plain ambiguous according to the setjmp() spec. In that situation, I'd prefer a conservative approach, restoring the "minimum necessary", whatever *that* might mean. :-( In fact, it makes me nervous that /usr/include/ppc/setjmp.h doesn't mention any qualifications about saving r13-r31 and fr14-fr31, which would conflict with the gcc spec if any of those were to be declared a global register variable. I can work around this by avoiding setjmp/longjmp -- maybe that's even good for the soul! -- David
Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com