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

[Alexandre Oliva <aoliva at redhat dot com>]

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

> On Fri, 22 Nov 2013, Alexandre Oliva wrote:
>> > I prefer longer, more readable names (e.g. floating-point-environment).
>> 
>> But that's meaningless.  Well, yeah, I understand

> It names the state used by the function.

Yeah, but what about that state?  Does the function read from it, so it
shouldn't be modified concurrently?  Or is it just that it modifies it,
just as the docs say it does?  Or is it that it temporarily sets it to
something else, but restores it later, so signal handlers that might
interrupt it should be aware of that?  Or maybe it requires it to be set
in certain ways, otherwise it could misbehave?  Or is it none of the
above?  Seriously?  What good is that?

And what is it that makes it better than e.g. fpenv?  Not to mention
that both are *equally* insufficient *and* misleading in conveying
information about what the problem is: that the function modifies the
floating point environment but does not restore it, but signal handlers
ought to restore it, so callers should beware.

>> We actually have good, settled precedent in using non-English keywords
>> in error codes that may be stored in errno.

> "I would have spelled creat with an 'e'.".

Why not open_and_truncate_existing_file_or_create_file_with_mode?

That would be far superior, for it would make it crystal clear.

:-/


>> Anyway...  What now?  Should the manual even mention this caveat when it
>> doesn't seem to document the deprecated feature at all?

> While I'd quite like to deprecate this functionality and even get the 
> _LIB_VERSION checks completely out of the runtime code paths for normal 
> calls to libm functions from new binaries, the manual does document 
> matherr:

>   @findex matherr
>   In the System V math library, the user-defined function @code{matherr}
>   is called when certain exceptions occur inside math library functions.
>   However, the Unix98 standard deprecates this interface.  We support it
>   for historical compatibility, but recommend that you do not use it in
>   new programs.

> It just doesn't mention the need to set _LIB_VERSION (the matherr manpage 
> does mention that).

Nothing mentions _LIB_VERSION in our manual, so the rest of the manual
might as well regard it as a constant.  Since glibc never sets itself up
so that libm behaves like SysV's libm, it wouldn't be out of question
IMHO to take the SysV behavior as if it was absent, since _LIB_VERSION
is unspecified, and from that conclude (or decree) that modifying it is
unsafe.

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