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: Alexandre Oliva <aoliva at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <codonell at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 23 Jan 2014 16:22:24 -0200
- 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> <Pine dot LNX dot 4 dot 64 dot 1401231606360 dot 31884 at digraph dot polyomino dot org dot uk>
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