This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Refactor part of math Makefile
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 14 Jun 2016 21:37:07 +0000
- Subject: Re: [PATCH] Refactor part of math Makefile
- Authentication-results: sourceware.org; auth=none
- References: <8d257095-c2da-0b8c-1740-00c8552d4ec8 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606142059280 dot 10937 at digraph dot polyomino dot org dot uk> <46f69224-4dc1-2c04-613f-0c940b88e4c8 at linux dot vnet dot ibm dot com>
On Tue, 14 Jun 2016, Paul E. Murphy wrote:
> > Given the conclusion that we should obsolete matherr / _LIB_VERSION as
> > part of the preparation for adding a new type, k_standard should end up in
> > the set of compat calls as well. (The new cleaner wrappers used for new
> > types, and for static linking / new ports for existing types, would handle
> > errno setting directly without calling __kernel_standard.)
>
> Is there a reason not to continue calling the function __kernel_standard
> and build a compat variant named __kernel_standard_compat to preserve the
> legacy behavior (with similar additions to this variable).
__kernel_standard is a very strange interface involving an enumerated list
of functions and recomputing error returns. It's not something to
replicate for new types. The natural approach is:
* Call the function being wrapped (unconditionally), which will set
exceptions and produce an appropriate return.
* Check for NaN / infinity / zero (as appropriate) as results, and set
errno directly instead of calling __kernel_standard, and return the
original error value instead of recomputing it.
No __kernel_standard. No checks on the writable global (not thread-local)
variable _LIB_VERSION.
Note: it's likely that various existing function implementations do not in
fact get their error returns right, and this is invisible in testing
because those original error returns are overridden by __kernel_standard
unless you use -lieee. So when adding cleaner wrappers to be used for new
types and ports and static linking, it's important to test them to find
and fix such cases (which are user-visible bugs, though fairly obscure
ones).
> >> +libm-tests = $(foreach t,$(types),test-$(t) \
> >> + test-$(t)-finite \
> >> + test-i$(subst ldouble,ldoubl,$(t))) \
> >
> > I don't think we should keep the irregularity of the test being called
> > test-ildoubl rather than ildouble. Rename it and you no longer need a
> > special $(subst ldouble,ldoubl,$(t)).
>
> I'm happy to oblige there. Do you happen to know the reason for the odd
> naming?
My guess would be long-ago 14-character limits on filenames
(test-ildouble.c is 15 characters). We no longer need to care about that
and have filenames up to 34 characters in glibc (e.g.
pthread_mutexattr_getprioceiling.c), and git uses filenames longer than
that.
--
Joseph S. Myers
joseph@codesourcery.com