Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70962
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.45 cause and error)
Message-ID: <52C5B5E1.5050609@lerdorf.com>
Date: Thu, 02 Jan 2014 10:54:25 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Robert Stoll <php@tutteli.ch>, internals@lists.php.net
References: <001801cf07e9$a07af1e0$e170d5a0$@tutteli.ch>
In-Reply-To: <001801cf07e9$a07af1e0$e170d5a0$@tutteli.ch>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="bJsI31VAQQU9uCDmGfg25juSwUl1CwLn3"
Subject: Re: [PHP-DEV] NAN and INF cast to int
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--bJsI31VAQQU9uCDmGfg25juSwUl1CwLn3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/2/14, 10:36 AM, Robert Stoll wrote:
> Another behaviour which I find strange is that a division by 0 yields f=
alse and not NAN:
> var_dump(1.5/0) ;       // boolean false
>=20
> I am aware of that introducing an E_WARNING would be somewhat a BC brea=
k but I still suggest to consider it because I
> rather see it as a bug. Consider the following example:
> $f =3D INF; //somehow INF was assigned to $f at some point
> $g =3D $f - 1; //$g is still INF -> correct IMO
> $h =3D (int) $g; // $i =3D 0; -> the value as such is ok IMO but it sho=
uld trigger an E_WARNING
> $i =3D $h - 1; //$i =3D -1 -> especially hard to detect if one does fur=
ther calculations with such a value

Are you testing on Windows? Things are a little odd there with its
32-bit ints on a 64-bit OS. There is a lot of work going on right now to
clean up the Windows situation. (int)INF is not 0 on 64-bit Linux.
INF/NAN convert to 0x8000000000000000 if you force a cast which is why
when you cast it to bool you get true.

The reason for 0x8000000000000000 is not a PHP thing but an x86-64
convention. This value is the indefinite integer value and basically
just tells you that you performed an action that is not defined. And
given that it is not defined, you cannot rely on the behaviour which
might be why on your platform you are getting zero. Although the
subsequent casts you show indicate it isn't actually zero.

I don't see anything incorrect here, but I agree we probably could add
an E_WARNING to some of these edge cases in addition to the one we have
for division by zero.

-Rasmus


--bJsI31VAQQU9uCDmGfg25juSwUl1CwLn3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlLFteEACgkQlxayKTuqOuBM3gCdEcVMX0E4kUy2gHxXnCMet+lp
bucAmgIilV1R5FDsQlDEvkxnx5wEp1wr
=w3w+
-----END PGP SIGNATURE-----

--bJsI31VAQQU9uCDmGfg25juSwUl1CwLn3--