svn commit: r209110 - in head/lib/msun: . src
David Schultz
das at freebsd.org
Thu Dec 2 04:57:30 UTC 2010
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 <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.
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.
More information about the svn-src-head
mailing list