This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, 19 Nov 2013, Carlos O'Donell wrote:

> Regarding the documenting of a bug for which a patch exists, that is
> now in Alex's court to remove the documentation for that since you've
> just checked in your patch for powerpc-nofpu floating point state
> after Adhemerval's (IBM) review.

Although the simfpu annotations are now obsolete, there's still I think a 
use for another annotation or two for affected functions, as a matter of 
AS-Safety not MT-Safety:

* libm functions generally may set the thread-local errno.  If a signal 
handler calls such a function without saving and restoring errno, whatever 
code in the thread was interrupted may see an unexpected errno change, and 
libc code may not be robust against errno changing asynchronously during a 
libc function.  (I don't know if there are functions beyond the libm and 
strtod/atof families that are AS-Safe but with an errno caveat.)

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

There's also an issue for both MT-Safety and AS-Safety:

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

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

[*] Properly deprecating _LIB_VERSION and matherr so that new programs 
can't use the different error handling modes at all and don't involve any 
runtime checks for them would need new symbol versions for lots of 
functions, and even them I'm not sure it would be possible to stop new 
programs providing a definition of _LIB_VERSION and finding it doesn't 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]