This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

isinf oddity


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]