This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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: Fri, 22 Nov 2013 13:01:38 -0200
- 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> <Pine dot LNX dot 4 dot 64 dot 1311211304050 dot 14539 at digraph dot polyomino dot org dot uk> <orzjoxro50 dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311221326100 dot 5029 at digraph dot polyomino dot org dot uk>
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