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

- Thread: https://externals.io/message/99698
- Original archive: https://news-web.php.net/php.internals/99698
- Started by Dmitry Stogov on 2017-07-03T07:03:00+00:00
- Messages: 5
- 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

---

## #99698 — Dmitry Stogov — 2017-07-03T07:03:00+00:00

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

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.

---

## #99700 — Bob Weinand — 2017-07-03T07:11:09+00:00

URL: https://externals.io/message/99698#99700 · In reply to: #99698

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

---

## #99703 — Sara Golemon — 2017-07-03T14:06:28+00:00

URL: https://externals.io/message/99698#99703 · In reply to: #99698

> 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

---

## #99729 — Stanislav Malyshev — 2017-07-04T00:23:27+00:00

URL: https://externals.io/message/99698#99729 · In reply to: #99698

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

---

## #99730 — Dmitry Stogov — 2017-07-04T04:13:14+00:00

URL: https://externals.io/message/99698#99730

Hi,


I agree with Stas and Sara.

it's easier to revert the last optimization and return to 7.1 behavior (even if it's inconsistent).

Fixing this inconsistency in PHP-Next would require RFC.


Thanks. Dmitry.