Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Rasmus Lerdorf'" <rasmus@lerdorf.com>,
	<internals@lists.php.net>
References: <001801cf07e9$a07af1e0$e170d5a0$@tutteli.ch> <52C5B5E1.5050609@lerdorf.com>
In-Reply-To: <52C5B5E1.5050609@lerdorf.com>
Date: Thu, 2 Jan 2014 20:08:50 +0100
Message-ID: <003c01cf07ee$123e08e0$36ba1aa0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJ/fRdWvDY7Kzfg/9Kc358Lr8TUtwHAAYsWmQLecIA=
Content-Language: de-ch
Subject: RE: [PHP-DEV] NAN and INF cast to int
From: php@tutteli.ch ("Robert Stoll")


> -----Original Message-----
> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> Sent: Thursday, January 02, 2014 7:54 PM
> To: Robert Stoll; internals@lists.php.net
> Subject: Re: [PHP-DEV] NAN and INF cast to int
> 
> On 1/2/14, 10:36 AM, Robert Stoll wrote:
> > Another behaviour which I find strange is that a division by 0 yields false and not NAN:
> > var_dump(1.5/0) ;       // boolean false
> >
> > I am aware of that introducing an E_WARNING would be somewhat a BC break but I still suggest to consider it because
I
> > rather see it as a bug. Consider the following example:
> > $f = INF; //somehow INF was assigned to $f at some point
> > $g = $f - 1; //$g is still INF -> correct IMO
> > $h = (int) $g; // $i = 0; -> the value as such is ok IMO but it should trigger an E_WARNING
> > $i = $h - 1; //$i = -1 -> especially hard to detect if one does further 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

I am testing on Windows 7 64bit. 
I was not surprised about the result of the int conversion because it is erroneous conversion anyway, so one cannot rely
on the value. The only thing which surprised me was that no E_WARNING was triggered.

And the other part about division by 0 yields false. I rethought it and conclude that it makes somewhat sense for a
purely int division. However, it does not make sense for a floating point number division IMO and should be NAN or INF
instead as suggested by IEEE 754. 
Yet, since this would be a BC break I understand that it cannot be changed in 5.x but maybe in PHP 6?