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

[David Schultz]

On Wed, Dec 01, 2010, Garrett Cooper wrote:
> >> 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.

A few math library functions are in libc because they've always
been there historically, and it seems impractical to change that.
In a few cases, they're in libc because other parts of libc (e.g.,
printf) require their functionality anyway.  libm also depends on
libc, so the fact that a few things are in libc instead of libm
isn't a problem.

>     Arg -- please ignore this email. I did another search and you said
> isnanf, not isnan. It's not mentioned anywhere in POSIX land or in any
> of our manpages.
> Sorry bout that,
> -Garrett

In C99, isnan() is actually a type-generic macro, and in FreeBSD,
it expands to __isnanf() when the argument is a float.