# DVAL_TO_LVAL() change, different behavior

- Thread: https://externals.io/message/36986
- Original archive: https://news-web.php.net/php.internals/36986
- Started by Matt Wilmas on 2008-04-12T10:45:45+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #36986 — Matt Wilmas — 2008-04-12T10:45:45+00:00

URL: https://externals.io/message/36986#36986

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