Re: setjmp/longjmp changed in Tiger
Re: setjmp/longjmp changed in Tiger
- Subject: Re: setjmp/longjmp changed in Tiger
- From: "David N. Williams" <email@hidden>
- Date: Wed, 01 Jun 2005 11:58:10 -0400
- Organization: University of Michigan
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden