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 <o...@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... _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
