isinf oddity

[Carlos O'Donell]

On 11/28/2014 08:06 AM, Wilco Dijkstra wrote:
> Hi,
> 
> I noticed there is something odd with the definition of isinf in GLIBC: it returns the sign of the
> infinity in the result. This is bad as neither C99 nor C++11 define this, so any software written to
> take advantage of this will silently fail when a conforming implementation is used. Checking for the
> sign of an infinity is rarely needed, and it is even rarer to be performance critical. A grep
> through GLIBC revealed only a few uses in the printf code - all of which could be trivially fixed.
> It also means we could remove the __isinf_ns(f/l) variant and make it the default as this version is
> C99/C++11 conforming and is simpler/faster as a bonus.

How much faster? Could you add a microbenchmark for isinf for
all supported types and measure? See glibc/benchtests/README.

The fact that you stand to make it faster for standards
conforming applications is the only reason we might make
some kind of change.

Without performance numbers the present implementation meets
the requirements of the standard and is documented in the
glibc manual.
 
> So the question is why was this done? Is there a really convincing reason to keep the odd behaviour,
> and only for isinf (not for isnormal, isfinite, isnan)? Is there a reason to support 2 separate
> implementatons of isinf (eg. keep a __isinf_sign that has the existing behaviour)? Do we know
> whether this "feature" is used anywhere?

Roland probably thought it was a good idea in 1995 :-)

Given that the present implementation has been around
and documented for ~20 years, it will absolutely have to
stay around forever.

The only way I see this working is math/math.h changing
the selected implementation based on the standard option
selected by the compiler with defaults being the present
behaviour, and -std=c99 or others selecting stricter
conforming behaviour from a new set of functions.

Cheers,
Carlos.