Date: Wed, 1 Dec 2010 21:16:04 -0800 From: Garrett Cooper <gcooper@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r209110 - in head/lib/msun: . src Message-ID: <AANLkTik7gfgu90SfgCUmMOqaY==MP5aLY24WDNddukmK@mail.gmail.com> In-Reply-To: <20101202045728.GA19295@zim.MIT.EDU> References: <201006121732.o5CHW5Cs065722@svn.freebsd.org> <20100615084939.GL13238@deviant.kiev.zoral.com.ua> <20100615131443.GA93094@zim.MIT.EDU> <20101202045728.GA19295@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 1, 2010 at 8:57 PM, David Schultz <das@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: >> > > =A0 Introduce __isnanf() as an alias for isnanf(), and make the isna= n() >> > > =A0 macro expand to __isnanf() instead of isnanf() for float argumen= ts. >> > > =A0 This change is needed because isnanf() isn't declared in strict = POSIX >> > > =A0 or C99 mode. >> > > >> > > =A0 Compatibility note: Apps using isnan(float) that are compiled af= ter >> > > =A0 this change won't link against an older libm. >> > > >> > > =A0 Reported by: =A0 =A0Florian Forster <octo@verplant.org> >> > >> > May be, it makes sense to remove the default version for the isnan sym= bol ? >> >> Wouldn't this mean apps that use isnanf() directly will no longer >> compile? =A0isnanf() 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. =A0(isnan() and isnanf() are in libc because >> that's where they were historically.) =A0The 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? =A0Both 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. =A0__isnanf is only present in > libm in 9-CURRENT (due to the commit referenced above). =A0Because > 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. =A0On 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTik7gfgu90SfgCUmMOqaY==MP5aLY24WDNddukmK>