From owner-svn-src-all@FreeBSD.ORG Thu Dec 2 18:58:25 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC75106566B; Thu, 2 Dec 2010 18:58:25 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7B66E8FC08; Thu, 2 Dec 2010 18:58:25 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id oB2IwOxL028634; Thu, 2 Dec 2010 13:58:24 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id oB2IwO71028633; Thu, 2 Dec 2010 13:58:24 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 2 Dec 2010 13:58:24 -0500 From: David Schultz To: Garrett Cooper Message-ID: <20101202185824.GA28587@zim.MIT.EDU> Mail-Followup-To: Garrett Cooper , Kostik Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201006121732.o5CHW5Cs065722@svn.freebsd.org> <20100615084939.GL13238@deviant.kiev.zoral.com.ua> <20100615131443.GA93094@zim.MIT.EDU> <20101202045728.GA19295@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Kostik Belousov , svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG Subject: Re: svn commit: r209110 - in head/lib/msun: . src X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:58:26 -0000 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.