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

Garrett Cooper gcooper at FreeBSD.org
Thu Dec 2 05:16:06 UTC 2010


On Wed, Dec 1, 2010 at 8:57 PM, David Schultz <das at freebsd.org> 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.

    Yeah... it's going to be broken according to the manpage (manpage
explicitly calls out -lm and math.h) and POSIX (POSIX only calls out
math.h) as math.h lives in lib/msun for C apps:

$ find /usr/src/ -name math.h
/usr/src/contrib/libstdc++/include/tr1/math.h
/usr/src/contrib/libstdc++/include/c_compatibility/math.h
/usr/src/lib/msun/src/math.h

    So unless math.h is going to move to libc, I'd leave it alone if I
was making the final call.
Thanks,
-Garrett


More information about the svn-src-all mailing list