Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61462
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: <d951082bae40dc1f2bda7fb3adb72e08.squirrel@webmail.klapt.com>
Date: Thu, 19 Jul 2012 10:30:58 +0200
To: "Nikita Popov" <nikita.ppv@gmail.com>
Cc: "PHP internals" <internals@lists.php.net>
Reply-To: ab@php.net
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Integer overflows on float to int casts
From: ab@php.net ("Anatoliy Belsky")

Hi Nikita,

that's exactly the subject I've tripped over trying to fix (apparently
wrong) the issue #62477. The ticket is about LimitIterator accepting only
long for start and offset, but being able to accept an Iterator from
userland accepting floats for positions.

For instance, the snippet like this looks also not very well

$a = array(); $a[4000000000] = 42; print_r($a);

Array
(
    [-294967296] => 42
)

So the mess is a bit bigger then and the way to solve this should include 
more consistent APIs as well, IMO. Again :). At the moment internal
operations (like array having uint for positions) are a possible subset of
userland. However internal APIs should be always the superset.

Regards

Anatoliy

Am Do, 19.07.2012, 00:39 schrieb Nikita Popov:
> Hi internals!
>
> When a large floating point number is cast to an integer we currently
have very low-level C behavior (integer overflow and wraparound):
>
> $ /c/php-5.4.1/php -r 'var_dump((int) 4000000000);'
> int(-294967296)
>
> $ /c/php-5.4.1/php -r 'var_dump((int) 6000000000);'
> int(1705032704)
>
> As a fun fact, if you do the same thing with a string float the number
if clipped instead of wrapped:
>
> $ /c/php-5.4.1/php -r 'var_dump((int) "4000000000");'
> int(2147483647)
>
> This also applies to zend_parse_parameters. l arguments are wrapped, L
arguments are clipped.
>
> In my eyes this kind of behavior has nothing to do in PHP. PHP is a
high-level language, it shouldn't exhibit low-level stuff like integer
overflows and wraparound.
>
> I think that at least for zend_parse_parameters this should be
> changed. Overflowing float parameters should not be accepted. Instead
throw the usual E_WARNING and return FAILURE.
>
> I'm not sure though what one should do about the explicit (int) cast. My
preference would be to throw a notice and use the clipping
> behavior.
>
> Thoughts?
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>