Date: Thu, 2 Dec 2010 13:58:24 -0500 From: David Schultz <das@FreeBSD.ORG> To: Garrett Cooper <gcooper@FreeBSD.ORG> Cc: Kostik Belousov <kostikbel@gmail.com>, svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG Subject: Re: svn commit: r209110 - in head/lib/msun: . src Message-ID: <20101202185824.GA28587@zim.MIT.EDU> In-Reply-To: <AANLkTinrkc_CiwCJ7tRpwcaF=9F7eRnoNn9ixH25J=UF@mail.gmail.com> References: <201006121732.o5CHW5Cs065722@svn.freebsd.org> <20100615084939.GL13238@deviant.kiev.zoral.com.ua> <20100615131443.GA93094@zim.MIT.EDU> <20101202045728.GA19295@zim.MIT.EDU> <AANLkTik7gfgu90SfgCUmMOqaY==MP5aLY24WDNddukmK@mail.gmail.com> <AANLkTinrkc_CiwCJ7tRpwcaF=9F7eRnoNn9ixH25J=UF@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101202185824.GA28587>