This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH 03/??] MT-, AS- and AC-Safety docs: manual/arith.texi
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: <codonell at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 23 Jan 2014 16:17:53 +0000
- Subject: Re: [MTASCsft PATCH 03/??] MT-, AS- and AC-Safety docs: manual/arith.texi
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <or4n4uoncj dot fsf at livre dot home> <orr47yn3kl dot fsf_-_ at livre dot home>
On Thu, 23 Jan 2014, Alexandre Oliva wrote:
> @@ -1053,6 +1082,7 @@ functions:
> @comment fenv.h
> @comment ISO
> @deftypefun int fesetenv (const fenv_t *@var{envp})
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> Set the floating-point environment to that described by @var{envp}.
Functions such as fesetenv may, if interrupted, leave the floating-point
environment in a partially updated state. For example, on x86_64 the x87
environment might have been updated but not the SSE environment - so traps
on exceptions might be enabled for only one of those environments, or the
rounding mode might be different in the two environments. The same
applies to many libm functions that internally use fesetround / fesetenv /
feholdexcept / feupdateenv etc., or the internal versions thereof (and we
certainly don't want to make any API guarantees about *which* functions
involving floating point do or do not make such temporary changes).
Subsequently called glibc functions may misbehave when called in such an
inconsistent environment. Should it be clarified somewhere how this is /
is not considered an AC-safety issue? (You already have the note about
AS-safety and the floating-point environment.)
--
Joseph S. Myers
joseph@codesourcery.com