This is the mail archive of the
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>, Torvald Riegel <triegel at redhat dot com>
- Date: Thu, 21 Nov 2013 13:21:24 +0000
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311182312130 dot 8831 at digraph dot polyomino dot org dot uk> <528BA2DA dot 3090608 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311192205550 dot 8742 at digraph dot polyomino dot org dot uk> <ortxf6tcpk dot fsf at livre dot home>
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
> 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