This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MTASCsft PATCH 03/??] MT-, AS- and AC-Safety docs: manual/arith.texi


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]