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 There's been a change in how setjmp/longjmp behaves between Panther and Tiger. In particular, the floating point rounding direction in Tiger gets restored to what it was at the time of the call to setjmp(), whereas in Panther it remains what it was at the time of the call to longjmp(). Here's a source file that demonstrates the change: ------ testsetjmp.c --------- #include <stdio.h> #include <setjmp.h> #include <fenv.h> jmp_buf mybuf; void change_round ( int round ) { fesetround ( round ); printf ("\nrounding direction changed to %i", fegetround() ); longjmp ( mybuf, 15 ); /* 15, just to see what happens */ } int main (void) { int status; printf ("\nrounding direction before setjmp is %i", fegetround() ); status = setjmp (mybuf); if ( status !=0 ) { printf ("\nstatus = %i", status); printf ( "\nrounding direction after longjmp is %i\n", fegetround() ); return 1; } change_round (FE_DOWNWARD); return 0; } ----------------------------- Here are the results on my wife's G4 Panther system (OS X 10.3.8, Xcode 1.5): ----------------------------- [euler:~/pfe] dnwills% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) [euler:~/pfe] dnwills% gcc -o testsetjmp testsetjmp.c [euler:~/pfe] dnwills% testsetjmp rounding direction before setjmp is 0 rounding direction changed to 3 status = 15 rounding direction after longjmp is 3 [euler:~/pfe] dnwills% ----------------------------- Here are the results on my G4 Tiger system (OS X 10.4.1, Xcode 2): ----------------------------- [jost:~/pfe] dnwills% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1809) [jost:~/pfe] dnwills% gcc -o testsetjmp testsetjmp.c [jost:~/pfe] dnwills% testsetjmp rounding direction before setjmp is 0 rounding direction changed to 3 status = 15 rounding direction after longjmp is 0 [jost:~/pfe] dnwills% ----------------------------- The Tiger results are the same with gcc 4.0.0. The Tiger behavior seems like a bug to me, but maybe I misunderstand? To quote from the Single Unix 3 spec for longjmp(): ----------------------------- SYNOPSIS #include <setjmp.h> void longjmp(jmp_buf env, int val); DESCRIPTION [CX] [Option Start] The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std 1003.1-2001 defers to the ISO C standard. [Option End] The longjmp() function shall restore the environment saved by the most recent invocation of setjmp() in the same thread, with the corresponding jmp_buf argument. If there is no such invocation, or if the function containing the invocation of setjmp() has terminated execution in the interim, or if the invocation of setjmp() was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined. [CX] [Option Start] It is unspecified whether longjmp() restores the signal mask, leaves the signal mask unchanged, or restores it to its value at the time setjmp() was called. [Option End] 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: * They are local to the function containing the corresponding setjmp() invocation. * They do not have volatile-qualified type. * They are changed between the setjmp() invocation and longjmp() call. ----------------------------- I believe this says that the floating point state at the time of the longjmp() call should persist. Is the Tiger behavior a bug? If so, I'll file a bug report. Please let me know what you think. Thanks, -- 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