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

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 21 Nov 2013, Alexandre Oliva wrote:

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

You could then put something in the general definition of what AS-Safe 
means.

> 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

And set all registers to initial values when the handler is called, rather 
than calling it with any registers in the state they were at the time the 
thread was interrupted?

What about the prctl state that forms part of the floating-point 
environment on powerpc (classic hard float and to a larger extent e500) - 
does that get preserved across signal handling and set to a known-good 
state during a signal handler?

> Should I bring simfpu back, named, hmm...  fpresenv?  And then add a

I prefer longer, more readable names (e.g. floating-point-environment).

> > * 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 ;-)

See for example math/w_pow.c - the pow function is documented in 
math.texi.  And sysdeps/ieee754/k_standard.c for what's covered by the 
__kernel_standard calls (which includes writing to streams).

> > (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?

Well, it's unsafe to call any affected function concurrently with changes 
to the global _LIB_VERSION, obviously, and it's specifically _SVID_ that 
(as described at 
<https://sourceware.org/ml/libc-alpha/2013-04/msg00767.html>) can result 
in an error message to stderr if matherr returns zero.  Eliminating 
support for _LIB_VERSION and matherr for new programs would eliminate this 
issue from needing documentation, but also be a fair amount of work and I 
don't know how symbol versioning and compat symbols would work for such 
cases where the user's program defines a symbol for libm to use.

-- 
Joseph S. Myers
joseph@codesourcery.com