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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jan 23, 2014, "Joseph S. Myers" <joseph@codesourcery.com> wrote:

> 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.

Yeah, thanks for bringing this to my attention.  I see two scenarios
here.

- the functions are interrupted by a signal whose handler relies on the
FP env.  IIRC that's what the existing observation covers, but it makes
me wonder if the functions that rely on the FP env become AS-Unsafe
because the FP env might be in an inconsistent state.  I didn't think
so, because it was clear that signal handlers had to set up their own FP
environment to be on the safe side.

- the functions are interrupted by an asynchronous cancellation.  the
thread-local FP enviroment may be left to die in a corrupt state along
with the rest of the thread.  The one point of concern is cleanup
handlers, should they rely on the FP environment being set in a specific
way.  Considering that they could be called even from within signal
handlers that override the FP environment, that wouldn't be advisable,
so they should set up the FP environment for their own execution just
like signal handlers have to.

Now, should any of this be added to the docs, or even be explicitly
marked as a safety issue?  I lean towards leaving that as âobvious
consequences of the way FP env works and the bits we've already
documentedâ, but... maybe they're not that obvious ;-)

I'm very open to revisiting this, be it right now (if the conclusion is close enough
to âno further actionâ or adding a note somewhere) or after 2.19 (if it
requires some major review and we agree the preliminary: note covers any
present shortcoming :-)

What kind of change do you suggest to bring us this issue into a
âsufficiently documentedâ state?

Thanks again,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist     Red Hat Brazil Toolchain Engineer