Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36986
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.235.148.22 cause and error)
Message-ID: <200804121045.m3CAjj0q016899@mail12c35.nsolutionszone.com>
Message-ID: <00c201c89c8a$5da1e4d0$0201a8c0@pc1>
To: <internals@lists.php.net>
Date: Sat, 12 Apr 2008 05:45:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: DVAL_TO_LVAL() change, different behavior
From: php_lists@realplain.com ("Matt Wilmas")

Hi all,

I have some code where I need to grab the last 1-3 bytes from numbers
(bitwise AND), and a few weeks ago I was looking to see how I'd handle the
possible, though unlikely, scenario of numbers > LONG_MAX (still only care
about those last bytes).  But I realized it worked just fine with the &
operator (because of how overflow worked converting a double operand), and
could rely on that without needing an additional check/workaround.  That was
with PHP 5.2.

I remembered the DVAL_TO_LVAL() macro was changed in Dec. and checked things
just now with 5.3.  Of course it's different with this code:

$num = PHP_INT_MAX * 2 + 1;

echo
(int) ($num + 1), "\n",
$num++ & 255, "\n",
$num++ & 255, "\n",
$num++ & 255, "\n",
$num   & 255, "\n";

$num = -PHP_INT_MAX;

echo
$num-- & 255, "\n",
$num-- & 255, "\n",
$num-- & 255, "\n",
$num   & 255;

5.2 result:
0
255
0
1
2
1
0
255
254

5.3 result:
2147483647
255
255
255
255
1
0
0
0

No overflow now, except between LONG_MAX and ULONG_MAX.

It was changed for bug #42868, which is about a string function?!  I see the
problem with overflow wrongly creating a negative start/offset param, etc.
but do people really have >2GB strings that they are passing values >
PHP_INT_MAX??  That bug refers to #30695, which resulted in a similar change
being reverted.  The only difference is the earlier change caused a problem
at LONG_MAX, which this works around, only to move the same issue to
ULONG_MAX.

Looks like the overflow-no-matter-what behavior has always been there (with
just a small tweak in 2001 -- zend_operators.c v1.105).  I think I've seen
some commits elsewhere similar to the strspn() fix posted in the bug
report...  That seems like a better way for these edge cases; or maybe a new
thing (conversion specifier?) for zend_parse_parameters() to limit longs to
LONG_MIN/LONG_MAX without overflow.

So can the traditional, legacy overflow behavior be restored?


Thanks,
Matt