From owner-svn-src-all@FreeBSD.ORG Thu Dec 2 09:57:26 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 0AF0D1065675; Thu, 2 Dec 2010 09:57:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 901AB8FC26; Thu, 2 Dec 2010 09:57:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oB29urjl012527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Dec 2010 11:56:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oB29uqUL051260; Thu, 2 Dec 2010 11:56:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oB29uqo0051259; Thu, 2 Dec 2010 11:56:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Dec 2010 11:56:52 +0200 From: Kostik Belousov To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: <20101202095652.GQ2392@deviant.kiev.zoral.com.ua> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="avqUsdiGFGJoDW7x" Content-Disposition: inline In-Reply-To: <20101202045728.GA19295@zim.MIT.EDU> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: 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 09:57:26 -0000 --avqUsdiGFGJoDW7x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 01, 2010 at 11:57:28PM -0500, David Schultz 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 > > > >=20 > > > > Log: > > > > Introduce __isnanf() as an alias for isnanf(), and make the isnan= () > > > > macro expand to __isnanf() instead of isnanf() for float argument= s. > > > > This change is needed because isnanf() isn't declared in strict P= OSIX > > > > or C99 mode. > > > > =20 > > > > Compatibility note: Apps using isnan(float) that are compiled aft= er > > > > this change won't link against an older libm. > > > > =20 > > > > Reported by: Florian Forster > > >=20 > > > May be, it makes sense to remove the default version for the isnan sy= mbol ? > >=20 > > 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). > >=20 > > 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. >=20 > 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. >=20 > 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. Both libc and libm export FBSD_1.X versions. For isnanf, both libc and libm export isnanf@FBSD_1.0, this means that isnanf can be removed from libm (we do not believe that some binary or library links against libm but not libc). For __isnanf, libc exports __isnanf@FBSD_1.0, and libm exports __isnanf@FBSD_1.2. I suspect that we could export both __isnanf@FBSD_1.0 and __isnanf@FBSD_1.2 from libc. Then, isnanf and __isnanf may be removed from libm. --avqUsdiGFGJoDW7x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkz3bWQACgkQC3+MBN1Mb4ic6QCgg4MaOkshd0V8nUQmBZ2mmuvJ YegAnjZh4IXkn/qbKbmLsqy4jFJpNpR7 =/gpl -----END PGP SIGNATURE----- --avqUsdiGFGJoDW7x--