# fix bug #53432 (Assignment via string index access on an empty string converts to array)

- Thread: https://externals.io/message/70213
- Original archive: https://news-web.php.net/php.internals/70213
- Started by Yasuo Ohgaki on 2013-11-19T23:47:30+00:00
- Messages: 10
- 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

---

## #70213 — Yasuo Ohgaki — 2013-11-19T23:47:30+00:00

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

Hi all,

This PR seems good fix for 5.6.

https://github.com/php/php-src/pull/463

Test script:
---------------
$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"

$b = ' '; // non empty string
$b[10] = 'b';
echo $b; // "          b"

Expected result:
----------------
"          a"
"          b"

Actual result:
--------------
"Array"
"          b"

Current behavior does not make sense.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #70236 — Nikita Popov — 2013-11-20T15:26:38+00:00

URL: https://externals.io/message/70213#70236 · In reply to: #70213

> Hi all,
>
> This PR seems good fix for 5.6.
>
> https://github.com/php/php-src/pull/463
>
> Test script:
> ---------------
> $a = ''; // empty string
> $a[10] = 'a';
> echo $a; // "Array"
>
> $b = ' '; // non empty string
> $b[10] = 'b';
> echo $b; // "          b"
>
> Expected result:
> ----------------
> "          a"
> "          b"
>
> Actual result:
> --------------
> "Array"
> "          b"
>
> Current behavior does not make sense.
>

The current behavior is that anything "falsey" (e.g. null, false and the
empty string) is silently cast to array when an array operation is applied
to it. I don't like that behavior, but it's somewhat internally consistent
now. Changing it for strings *only* seems a bit weird.

Nikita

---

## #70249 — Yasuo Ohgaki — 2013-11-20T21:38:13+00:00

URL: https://externals.io/message/70213#70249 · In reply to: #70236

Hi Nikita,



> The current behavior is that anything "falsey" (e.g. null, false and the
> empty string) is silently cast to array when an array operation is applied
> to it. I don't like that behavior, but it's somewhat internally consistent
> now. Changing it for strings *only* seems a bit weird.


Persuasive argument.
I prefer to change the behavior if I have to choose, though.

$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"

would be common pit hole when users are trying to use string as array of
chars.
I don't know why, but there are 436 FB likes! for this PR even if there is
no "likes!"
button on the page. There may be a lot of users that are unhappy with this
behavior.

Document and warn users?
Or should we change behavior even if it seems odd?

I don't mind at all setting up RFC to vote.
Any comments?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #70250 — Yasuo Ohgaki — 2013-11-20T21:48:39+00:00

URL: https://externals.io/message/70213#70250 · In reply to: #70249

Hi all,



> I don't know why, but there are 436 FB likes! for this PR even if there is
> no "likes!"
>  button on the page. There may be a lot of users that are unhappy with
> this behavior.
>

The number of likes! are the same as "php-src".
I guess Facebook is ignoring the path :)

Anyway, are we going to document the behavior?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #70251 — Andrea Faulds — 2013-11-20T21:49:26+00:00

URL: https://externals.io/message/70213#70251 · In reply to: #70249

> Hi Nikita,
>
> 
>
> > […]
>
>
> Persuasive argument.
> I prefer to change the behavior if I have to choose, though.
>
> $a = ''; // empty string
> $a[10] = 'a';
> echo $a; // "Array"
>

Just my 2 cents, but that definitely looks like a situation that might 
crop up in real code unintentionally, and it violates the Principle of 
Least Astonishment IMO. Consider a hypothetical function which returns a 
modified string. If we've ended up with an empty string being passed 
into it, then it suddenly returning an Array is not what you expect, and 
might horribly break code that assumes the result won't be a string.

-- 
Andrea Faulds
http://ajf.me/

---

## #70252 — Andrea Faulds — 2013-11-20T21:53:17+00:00

URL: https://externals.io/message/70213#70252 · In reply to: #70251

>
> Just my 2 cents, but that definitely looks like a situation that might
> crop up in real code unintentionally, and it violates the Principle of
> Least Astonishment IMO. Consider a hypothetical function which returns a
> modified string. If we've ended up with an empty string being passed
> into it, then it suddenly returning an Array is not what you expect, and
> might horribly break code that assumes the result won't be a string.
>

Oh dear Andrea, you should proofread your emails better.
s/won't be/will be

-- 
Andrea Faulds
http://ajf.me/

---

## #70253 — Yasuo Ohgaki — 2013-11-20T22:02:05+00:00

URL: https://externals.io/message/70213#70253 · In reply to: #70252

Hi Andrea,



> 
>
> > […]
> Oh dear Andrea, you should proofread your emails better.
> s/won't be/will be


I agree with your discussion and that's the reason why I sending
this PR before I said "it's the spec".

I've added this behavior to RFC (NOT for voting)
https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparison

I'm gathering these kind of PHP behaviors. If you have one, please let me
know so that I can add issues in the wiki page. (Or even better, please add
one to the page)

Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #70267 — Stas Malyshev — 2013-11-21T19:49:41+00:00

URL: https://externals.io/message/70213#70267 · In reply to: #70253

Hi!

> I've added this behavior to RFC (NOT for voting)
> https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparison

I'm not sure behavior that is documented and implemented exactly as it
was planned (e.g. `min()` behavior) can be called "inconsistency". It is
actually completely consistent and does exactly what it is meant to do.
Same for dec/hex strings - it works exactly like strtod(). Of course it
does not support every numeric base in existence, but it was never
supposed to.

Also, "Null string is not handled as string" is not correct - null
string is handled as string, except in one narrow case where you apply
array operations to it. Right now it gives an impression empty strings
are not handled as strings in PHP at all, which is not correct.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #70270 — Yasuo Ohgaki — 2013-11-22T00:27:23+00:00

URL: https://externals.io/message/70213#70270 · In reply to: #70267

Hi Stas,

It might be better to change RFC title.
My goal is sort out PHP behaviors which may seem strange.

If it's a bug, fix it. if not, document it so that users understand
what it suppose to do.

On Fri, Nov 22, 2013 at 4:49 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > […]
>
> I'm not sure behavior that is documented and implemented exactly as it
> was planned (e.g. `min()` behavior) can be called "inconsistency". It is
> actually completely consistent and does exactly what it is meant to do.
> Same for dec/hex strings - it works exactly like strtod(). Of course it
> does not support every numeric base in existence, but it was never
> supposed to.
>

I agree. It's the way PHP works.

It might be better to document these, since there are many languages out
there and people have different expectations.


> Also, "Null string is not handled as string" is not correct - null
> string is handled as string, except in one narrow case where you apply
> array operations to it. Right now it gives an impression empty strings
> are not handled as strings in PHP at all, which is not correct.


I've updated to
"Null string is handled as array" when string is accessed as array of char.
I appreciate better explanation :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #70274 — Yasuo Ohgaki — 2013-11-22T01:43:50+00:00

URL: https://externals.io/message/70213#70274 · In reply to: #70270

Hi Stas,



> It might be better to change RFC title.
> My goal is sort out PHP behaviors which may seem strange.
>
> If it's a bug, fix it. if not, document it so that users understand
> what it suppose to do.
>

I've changed the title to

RFC: Existing comparison and conversion behaviors to discuss/document
https://wiki.php.net/rfc/comparison_inconsistency

This title might be better than old one.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net