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

Am 03.07.2017 um 09:03 schrieb Dmitry Stogov <dmitry@zend.com<mailto: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

On Mon, Jul 3, 2017 at 3:03 AM, Dmitry Stogov <dmitry@zend.com> wrote:

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!

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.