• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
setjmp/longjmp changed in Tiger
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

setjmp/longjmp changed in Tiger


  • Subject: setjmp/longjmp changed in Tiger
  • From: "David N. Williams" <email@hidden>
  • Date: Sat, 28 May 2005 22:47:49 -0400
  • Organization: University of Michigan

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      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: setjmp/longjmp changed in Tiger
      • From: Matt Watson <email@hidden>
  • Prev by Date: Re: __builtin_frame_address()
  • Next by Date: Re: setjmp/longjmp changed in Tiger
  • Previous by thread: Re: can virtual memory be suppressed?
  • Next by thread: Re: setjmp/longjmp changed in Tiger
  • Index(es):
    • Date
    • Thread