Re: [PATCH] Refactor part of math Makefile

[Joseph Myers <joseph at codesourcery 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