From owner-freebsd-current@FreeBSD.ORG Wed Jul 10 20:13:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55349B11; Wed, 10 Jul 2013 20:13:15 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6C09E1960; Wed, 10 Jul 2013 20:13:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUGADG/3VFR8aPm/2dsb2JhbABagwkywXGBExd0giMBAQVWIxALGAkWDwkDAgECASceBg0BBQIBAYgPuACPYwcJg2wDkA6BLYdIkCGBWIE7Og Received: from 230.163-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.163.230]) by relay.skynet.be with ESMTP; 10 Jul 2013 22:13:06 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r6AKD53P023353; Wed, 10 Jul 2013 22:13:06 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Message-ID: <51DDC04B.6040209@FreeBSD.org> Date: Wed, 10 Jul 2013 22:12:59 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130701 Thunderbird/17.0.7 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> In-Reply-To: <20130710203200.5359fd18@thor.walstatt.dyndns.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EQINXAXUJPBVPTPMIQWW" Cc: freebsd-standards@FreeBSD.org, FreeBSD CURRENT , David Chisnall , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:13:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EQINXAXUJPBVPTPMIQWW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-10 20:32, O. Hartmann wrote: > On Wed, 10 Jul 2013 18:04:16 +0100 > David Chisnall wrote: >=20 >> On 10 Jul 2013, at 17:33, "O. Hartmann" >> wrote: >> >>> Hi David, >>> >>> thanks for the fast response. >>> >>> The code I was told to check with is this: >>> >>> #include >>> #include >>> #include >>> >>> int >>> main(void) >>> { >>> >>> std::cout << typeid(isnan(1.0)).name() << "\n"; >>> >>> } >>> >>> >>> If I compile it with=20 >>> >>> c++ -o testme -std=3Dc++11 -stdlib=3Dlibc++ source.cc >>> >>> and run the binary, the result is "i" which I interpret as "INT". >> >> I believe there is a bug, which is that the math.h things are being >> exposed but shouldn't be, however it is not the bug that you think it >> is. Try this line instead: >> >> std::cout << typeid(std::isnan(1.0)).name() << "\n"; >> >> We have a libm function, isnan(), and a libc++ function, >> std::isnan(). The former is detected if you do not specify a >> namespace. I am not sure what will happen if you do: >> >> #include >> #include >> #include >> using namespace std; >> >> int >> main(void) >> { >> >> cout << typeid(isnan(1.0)).name() << "\n"; >> >> } >> >> This is considered bad form, but does happen in some code. I am not >> certain what the precedence rules are in this case and so I don't >> know what happens. >> >> To properly fix this, we'd need to namespace the libm functions when >> including math.h in C++. This would also include fixing tweaking the >> macros. =20 >> >> A fix for your code is to ensure isnan() and isinf() are explicitly >> namespaced. Potentially, this may also work: >> >> using std::isinf; >> using std::isnan; >> >> David >> >=20 > I tried in the test code I provided using=20 >=20 >=20 > #include > #include > #include >=20 > int > main(void) > { >=20 > std::cout << typeid(std::isnan(1.0)).name() << "\n"; >=20 > } >=20 > now std::isnan(). >=20 > The result is the same, it flags "INT". >=20 > Using=20 >=20 > #include > #include > #include >=20 > using namespace std; >=20 > int > main(void) > { >=20 > std::cout << typeid(std::isnan(1.0)).name() << "\n"; >=20 > } >=20 > which is considered "bad coding" also results in "INT" (it gives "i"). >=20 > So, is this woth a PR? isnan is overloaded. There's "int isnan(double)" in math.h and "bool isnan(arithmetic)" in cmath. When you call isnan(1.0), isnan(double) is selected. I think isnan(double) and isinf(double) in math.h should only be visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. For C99 and higher there should only be the isnan/isinf macros. CCed standards@. ------enig2EQINXAXUJPBVPTPMIQWW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iF4EAREIAAYFAlHdwFEACgkQfoCS2CCgtisMQwD9FoF5bcEWaWyVmEC5YXZKGLWd BYB0w68AI3sn0TyNdM0A/iFHD46Iybj5t3tc51SM9HPxom1uMg8HgBwj+shZgyt0 =n5uK -----END PGP SIGNATURE----- ------enig2EQINXAXUJPBVPTPMIQWW--