Re: Consensus on MT-, AS- and AC-Safety docs.

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 19, 2013, "Joseph S. Myers" <joseph@codesourcery.com> wrote:

> * libm functions generally may set the thread-local errno.

This is indeed quite an interesting issue, and it's definitely not a
problem limited to libm.

I can see it could have value to warn users that calling a function
within a signal handler requires a certain variable that might be
modified by the function to be restored before completing signal
handling.

However, I have three problems with that.

One is that nearly all functions may modify errno in certain
circumstances.  This means nearly every function would get a note, so it
might end up becoming background noise.

Another is that the issue is not so much a problem in the library
function itself (it *is* safe to call in this regard), but a problem
that callers ought to deal with.

Finally, by now I've audited more than 70%+ of the glibc code base
without taking notes on this issue, and, going back to all of them
wouldn't fit the timeframe of this project.

So, while these problems don't make me against the suggestion in
principle, I don't see myself taking care of it.

> (I don't know if there are functions beyond the libm and 
> strtod/atof families that are AS-Safe but with an errno caveat.)

I've taken note of (mis)features that make for safety issues regardless
of whether other such misfeatures apply.  The reason is to avoid getting
a wrong picture that fixing just one issue will make a function safe.


> * libm functions, and floating-point arithmetic, may use and modify the 
> floating-point environment.  Depending on the platform, the kernel may 
> arrange for a signal handler to get a clean environment and for changes it 
> makes to be discarded (in which case nothing special needs doing regarding 
> the floating-point environment when using floating point in signal 
> handlers), or it may not (in which case a signal handler using floating 
> point needs to save the environment it receives, set up a known-good 
> environment such as FE_DFL_ENV, and restore the old environment before 
> returning).  (Part of this caveat was included within the simfpu one.)

AFAICT kernels that libc targets preserve the FP environment across
signal handlers, just because they preserve the entire register file
over signal handling, so this was a non-concern as long as the fpu
environment was kept in a hw register.  Unfortunately, I now realize
that this doesn't hold for a simfpu environment that's not implemented
in hw registers, even if the registers are just simulated by the kernel,
so part of the simfpu issue is indeed uncovered.  And the fact that
kernels do restore the environment may mean programs won't take care of
it on their own, just as they might fail to restore errno.

Unlike errno, however, only a few functions modify the FP environment,
so it might make sense to keep the simfpu note as an AS (and AC?) safety
issue that indicates the need for a caller to preserve the FP env around
such functions within signal handlers.

Should I bring simfpu back, named, hmm...  fpresenv?  And then add a
note about the far more prevalent errno issue there, if nobody decides
to introduce the preserrno ;-) note.

> * Some libm functions read the _LIB_VERSION global variable (which may be 
> changed by users to change libm error handling modes, although I think 
> that functionality should be considered deprecated [*]).

> * Depending on the error handling mode, some libm functions call matherr 
> which may be provided by the user, and, depending on the return from 
> matherr, in _SVID_ mode write a message to stderr with fputs (sometimes 
> optimized to fwrite) (with whatever consequences for safety are implied by 
> use of those functions).

Eeek.  I don't recall auditing functions that do this.  I audited the
funtions in arith.texi a long time ago, and those in math.texi more
recently but not that recently, so I may have forgotten all about it.
But I'm now concerned I may have missed these behaviors entirely.  Are
they introduced by means of mazes of includes or macros that I may have
got lost in?  Are functions that do this documented in the manual?  (if
they aren't, and they aren't dependendencies of those that are, I'm
blind to them in this project ;-)

> I think the intended API for libm functions, not just the current 
> implementation properties, is to be MT-Safe, AS-Safe and AC-Safe with the 
> above caveats.

Yeah, but some of these caveats, such as writing to streams, would be
pretty hard to make AS-Safe, because of asynconsist, and AC-Safe,
because of incansist.

> (In particular, the uses of sprintf and qsort from libm are I think
> ones that should never result in malloc calls, and as long as you
> don't change _LIB_VERSION from its default value, the last two points
> never apply.)

Perhaps something along the lines of glocale and envromt, ruling it
unsafe to set _LIB_VERSION to certain values?

-- 
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 Compiler Engineer