svn commit: r209110 - in head/lib/msun: . src

[David Schultz]

On Tue, Jun 15, 2010, Kostik Belousov wrote:
> On Sat, Jun 12, 2010 at 05:32:05PM +0000, David Schultz wrote:
> > Author: das
> > Date: Sat Jun 12 17:32:05 2010
> > New Revision: 209110
> > URL: http://svn.freebsd.org/changeset/base/209110
> > 
> > Log:
> >   Introduce __isnanf() as an alias for isnanf(), and make the isnan()
> >   macro expand to __isnanf() instead of isnanf() for float arguments.
> >   This change is needed because isnanf() isn't declared in strict POSIX
> >   or C99 mode.
> >   
> >   Compatibility note: Apps using isnan(float) that are compiled after
> >   this change won't link against an older libm.
> >   
> >   Reported by:	Florian Forster <octo at verplant.org>
> 
> May be, it makes sense to remove the default version for the isnan symbol ?

Wouldn't this mean apps that use isnanf() directly will no longer
compile?  isnanf() is a historical BSD interface, and although
it's been deprecated for many years, it's still declared (if
__BSD_VISIBLE).

Oops, to complicate matters further, I just noticed that we
already have isnanf and __isnanf symbols in libc, so maybe the new
symbol isn't needed.  (isnan() and isnanf() are in libc because
that's where they were historically.)  The second version in
libm looks like a mistake (wrong scope of the #if 0 in s_isnan.c.)
Perhaps we could just remove the duplicate symbols from libm.

Better would be to remove the symbols from libc and have them in
libm where they belong, but I'm not sure if that would break anything.
Historically that was impractical due to the practice of bumping
the version number of libc, but not libm, every major release:
libm.so.2 had to be prepared to link against libc.so.4 for a 4.X
application and libc.so.5 for a 5.X application.

I also just noticed that there's no MLINK for isnanf, and there
probably never has been...