This is the mail archive of the
mailing list for the glibc project.
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: <libc-help at sourceware dot org>
- Date: Fri, 28 Nov 2014 13:06:54 -0000
- Subject: isinf oddity
- Authentication-results: sourceware.org; auth=none
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?