7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken View as Markdown

Am 03.07.2017 um 09:03 schrieb Dmitry Stogov <dmitry@zend.commailto:dmitry@zend.com>:

Hi,

Please take a look at https://bugs.php.net/bug.php?id=74836
What is the best option to fix this?

The most consistent way, from my point of view - disabling zero-prefexed numeric strings in all cases, but this is a new behavior break.

Thanks. Dmitry.

Hey,

yep, it's probably best to allow only reversible string->integer conversions here.
We also shall then emit an E_NOTICE error, just like on normal arrays.

I see no reason to let invalid indices just silently pass on strings.

Bob

Please take a look at https://bugs.php.net/bug.php?id=74836

What is the best option to fix this?

I'm more curious why we throw out numeric strings starting with
zeros in _zend_handle_numeric_str_ex()

But since the answer to that question probably lies down a long road
to even worse BC-breaksville, how about we revert your IS_CONST
optimization for 7.2 and give it the time it needs for 7.3?

-Sara

Hi!

Please take a look at https://bugs.php.net/bug.php?id=74836

What is the best option to fix this?

The most consistent way, from my point of view - disabling zero-prefexed numeric strings in all cases, but this is a new behavior break.

I think this is very corner case, for string offsets. So for 7.2 to drop
support for leading-0 string, with note in UPGRADING and maybe a
notice/warning, would be ok. It is not good though that read access and
isset are not consistent, this should always work the same. It is
especially worrying that "010" and $i = "010" work differently, that
should never happen.

The problem is if we disable it for string offsets, it would be weird to
keep it for array offsets, and so for arrays "010" should be treated as
string I guess? Which may involve more breakage. So I wonder if a better
way would be to just let it be as it always was, and maybe make
leading-0 strings not to be interpreted as numbers for both cases in
PHP.next when we can do BC breaks.

--
Stas Malyshev
smalyshev@gmail.com