From owner-svn-src-head@FreeBSD.ORG Thu Dec 2 05:17:38 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DF81065672; Thu, 2 Dec 2010 05:17:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEC238FC23; Thu, 2 Dec 2010 05:17:37 +0000 (UTC) Received: by wyf19 with SMTP id 19so7758376wyf.13 for ; Wed, 01 Dec 2010 21:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=JfLC2HNSLpxs7WWGkUR7kMlN+7gKN4ONEudpMKxOuho=; b=Ubz6a5BVje8dM7zeqX65yq2YLJfpfnHOoR6uZHR4svoxvSq8SXGRCEwHrQfEi7JwR4 WrC7a/iIUwMgwMe334apEf0kyI10hT1ejrwYJluS/UKrSWsDy5AuPkDKXKwSEQjunChI ZyKMd0fju391INowwfzaFWFPwiX10bNomrpdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=lnqxwDUIYhe+Uts5KiK+EXjl/wFTIFb9k6Opbau+Wsw2TzLS7jqDtnXz8txMfNkua/ jpBTZ6wt9PZxNYuM8ohKVbmz0A874Q/sTeUblLmy2KVX4Q0n1Eg3DqSHdO/m7EYTmg41 P+SH6kVXCVGyWNQavWsvLYbM05ICKeIwLJ35E= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr2910922wee.45.1291267056252; Wed, 01 Dec 2010 21:17:36 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 1 Dec 2010 21:17:36 -0800 (PST) In-Reply-To: References: <201006121732.o5CHW5Cs065722@svn.freebsd.org> <20100615084939.GL13238@deviant.kiev.zoral.com.ua> <20100615131443.GA93094@zim.MIT.EDU> <20101202045728.GA19295@zim.MIT.EDU> Date: Wed, 1 Dec 2010 21:17:36 -0800 X-Google-Sender-Auth: 39j35Hsq7nr8qujqKBVMzIn6x10 Message-ID: From: Garrett Cooper To: Kostik Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r209110 - in head/lib/msun: . src X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 05:17:39 -0000 On Wed, Dec 1, 2010 at 9:16 PM, Garrett Cooper wrote: > On Wed, Dec 1, 2010 at 8:57 PM, 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 >>> > > >>> > > Log: >>> > > =A0 Introduce __isnanf() as an alias for isnanf(), and make the isn= an() >>> > > =A0 macro expand to __isnanf() instead of isnanf() for float argume= nts. >>> > > =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 a= fter >>> > > =A0 this change won't link against an older libm. >>> > > >>> > > =A0 Reported by: =A0 =A0Florian Forster >>> > >>> > May be, it makes sense to remove the default version for the isnan sy= mbol ? >>> >>> 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. > > =A0 =A0Yeah... 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 > > =A0 =A0So unless math.h is going to move to libc, I'd leave it alone if I > was making the final call. 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