Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70972
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
Message-ID: <8c65be72cd24e97522ac630ca475e146.squirrel@webmail.klapt.com>
In-Reply-To: <003c01cf07ee$123e08e0$36ba1aa0$@tutteli.ch>
References: <001801cf07e9$a07af1e0$e170d5a0$@tutteli.ch>
    <52C5B5E1.5050609@lerdorf.com>
    <003c01cf07ee$123e08e0$36ba1aa0$@tutteli.ch>
Date: Thu, 2 Jan 2014 22:03:09 +0100
To: "Robert Stoll" <php@tutteli.ch>
Cc: "'Rasmus Lerdorf'" <rasmus@lerdorf.com>,
 internals@lists.php.net
Reply-To: "Anatol Belski" <ab@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: RE: [PHP-DEV] NAN and INF cast to int
From: ab@php.net ("Anatol Belski")

Hi Robert,

On Thu, January 2, 2014 20:08, Robert Stoll wrote:
>

>> -----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?
>
>

you might be interested on the int64 branch builds. Please fetch the
latest from here
http://windows.php.net/downloads/snaps/str_size_and_int64/r8260644/ . The
behavior of the INF/NAN case in that branch is identical to that on 64 bit
Linux. Also, you'll probably find one ore another astonishment regarding
win64 in there. I'd really appreciate your feedback.

Thanks

Anatol