On Wed, Dec 01, 2010 at 11:57:28PM -0500, David Schultz wrote: > On Tue, Jun 15, 2010, David Schultz wrote: > > 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. > > Any thoughts on removing the isnanf and __isnanf symbols from > libm? Both symbols are already in libc for historical reasons, so > the duplication isn't needed. > > Although we've had the duplicate isnanf symbol in libm for several > releases, I don't believe removing it will cause problems; apps > will just pick up the libc version. __isnanf is only present in > libm in 9-CURRENT (due to the commit referenced above). Because > of symbol version differences, however, removing it will affect > apps that were linked under 9-CURRENT AND rely on isnanf AND link > against libm before libc. On my system, libwebkit is the only > affected binary I could find.
Both libc and libm export FBSD_1.X versions. For isnanf, both libc and libm export isn...@fbsd_1.0, this means that isnanf can be removed from libm (we do not believe that some binary or library links against libm but not libc). For __isnanf, libc exports __isn...@fbsd_1.0, and libm exports __isn...@fbsd_1.2. I suspect that we could export both __isn...@fbsd_1.0 and __isn...@fbsd_1.2 from libc. Then, isnanf and __isnanf may be removed from libm.
pgptqYFPCDtZo.pgp
Description: PGP signature
