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

[Kostik Belousov]

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 <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.

Both libc and libm export FBSD_1.X versions. For isnanf, both
libc and libm export isnanf at 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 __isnanf at FBSD_1.0, and libm exports
__isnanf at FBSD_1.2. I suspect that we could export both
__isnanf at FBSD_1.0 and __isnanf at FBSD_1.2 from libc.

Then, isnanf and __isnanf may be removed from libm.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20101202/3fabf1ad/attachment.pgp