Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++:
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 <theraven@FreeBSD.org> wrote:
>=20
>> On 10 Jul 2013, at 17:33, "O. Hartmann" <ohartman@zedat.fu-berlin.de>
>> wrote:
>>
>>> Hi David,
>>>
>>> thanks for the fast response.
>>>
>>> The code I was told to check with is this:
>>>
>>> #include <iostream>
>>> #include <typeinfo>
>>> #include <cmath>
>>>
>>> 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 <iostream>
>> #include <typeinfo>
>> #include <cmath>
>> 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 <iostream>
> #include <typeinfo>
> #include <cmath>
>=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 <iostream>
> #include <typeinfo>
> #include <cmath>
>=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--
討論串 (同標題文章)
完整討論串 (本文為第 7 之 26 篇)：