isinf oddity

Wilco Dijkstra
Fri Nov 28 13:07:00 GMT 2014


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.

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?


More information about the Libc-help mailing list