2020/03/10 23:38

先日なんとなく、bugs.php.netにバグレポを提出しました。
中身は前書いた配列要素を削除するとインデックスが残ったり残らなかったりするの記事、というかそこに付いた @crhg さんのコメントそのまんまです。

When copy empty array, next key is unspecified

Description

Copy array.

When arrays next index=2 and max key=2, next key is both 2.
When arrays next index=2 and max key=1, next key is both 2.
When arrays next index=2 and max key=0, next key is 0 or 2.

Test script

$a = [1, 2];
$b = $a;

$a[] = 3;
$b[] = 4;

echo "When next index=2 and max key=2, next key is both 2.\n";
var_dump($a, $b); // $a = [0=>1, 1=>2, 2=>3]  $b = [0=>1, 1=>2, 2=>4]


$a = [1, 2];
unset($a[1]);
$b = $a;

$a[] = 3;
$b[] = 4;

echo "\nWhen next index=2 and max key=1, next key is both 2. \n";
var_dump($a, $b); // $a = [0=>1, 2=>3]  $b = [0=>1, 2=>4]


$a = [1, 2];
unset($a[1], $a[0]);
$b = $a;

$a[] = 3;
$b[] = 4;

echo "\nWhen next index=2 and max key=0, next key is 0 or 2.";
var_dump($a, $b); // $a = [0=>3]  $b = [2=>4]  what?


$a = [1, 2];
unset($a[1], $a[0]);
$b = $a;

$b[] = 4;
$a[] = 3;

echo "\nIf reverse variable, result is reverse too.\n";
var_dump($a, $b); // $a = [2=>3]  $b = [0=>4]  what??

$a = [1, 2];
unset($a[1], $a[0]);
$b = $c = $d = $a;

$a[] = 3;
$b[] = 4;
$d[] = 6;
$c[] = 5;

echo "\nWhen increase variables, only the last one take over key..\n";
var_dump($a, $b, $c, $d); // $c's key is 2, others are 0

Expected result

Always same key whth $a and $b.

Actual result

Same key when array is not empty.
Not same key when array is empty.

2020/03/11 00:17

cmb69氏から修正のプルリクが提出されました。
バグレポ提出からの時間、なんと40分。
はえーよ。

ちなみにコミット内容は追加22行変更1行ですが、うち追加22行はテストコードなので、実質的な変更は1行だけです。
変更内容は要素数が0のときもnNextFreeElementを引き継ぐようにするというもので、これまた @crhg さんのコメントのとおりです。

cmb69氏はRFCにはあまり出てこないので一見目立ちませんが、githubやbugs.php.netでは見ない日がないんじゃないかってくらい、バグフィックスやソースの整理などで大活躍しているメイン開発者の一人です。

2020/03/11 00:35

Nikitaから物言いがつく。

本当にインデックス継続でいいの？
リセットする方が正しいんじゃないか？
継続することにメリットはある？

などと言いつつApproveしています。ツンデレかよ。

Nikitaは最近最も仕事しているPHP開発者で、そしてガッチガチstrictぺちぱーの急先鋒です。

2020/03/11 17:13

このあたりでmasterにマージされました。

2020/04/16

この修正が取り込まれたPHP7.4.5がリリースされました。

ChangeLogに記載されました。
めでたし。

感想

実際にプルリクを出したりコードが採用されたりしたわけではないので、PHP本体に貢献できた！と堂々と主張できるかというと微妙ですが、自分の提案が影響を与えたかと思うとちょっとだけ嬉しいですね。

バグレポを出そう

Qiitaではどうもプルリクを出してようやく一人前、プルリクを出さずんば開発者に非ず、みたいな風潮がありますが、そこまでやらなくてもバグレポ程度でも役には立ちますよ、という趣旨の記事でした。
みんなもおかしなところを見つけたらバグレポを出しましょう。
もっとも、おかしいな、これはバグかな、って思った原因の99%は自分のコードが間違ってるからなので、確認と見極めが大切です。

まあ、私がプルリクを出さなかったのはひとえに面倒だったからというだけなので、プルリクを出せるようなら出した方がもっといいとは思いますけどね。

バグレポを出すにあたって気を付けること

最低限絶対必要なものは、『再現するコード』です。

今回私のバグレポが速攻で対応されたのも、再現するコードを3v4lで出したからというのが大きいと思います。
バグレポを見てのとおり私の英語力はとってもアレなうえ、"When arrays next index=2 and max key=2, next key is both 2"のところとか数値も間違っているというぐだぐだなバグレポだったのですが、しかし出力が明白なコードを付けたおかげで、意図した問題点は汲み取ってもらえました。

次いで『期待する結果』『実際の結果』も必要です。
これがないと、どう修正すればいいかわかりませんからね。
今回私はAlways same key whth $a and $b.と"揃えろ"だけ書いていて、"〇〇に揃えろ"のように具体的な値を示していません。
これは0にしたほうがいいのか2にしたほうがいいのかわからなかったからです。
いわゆるひとつのお任せします(責任転嫁)というやつです。

あとは『再現環境』です。
今回みたいに3v4lで再現するなら特に気にする必要もないと思いますが、CLIでしか発生しないとか、Windows環境でしか発生しないとか、そういう場合は記載が必要となるでしょう。

このように『再現するコード』『期待する結果』『実際の結果』『再現環境』をきちんと揃えることで、デバッガの人も対応しやすくなります。
その程度当然じゃないかと思うかもしれませんが、意外とできていない人が多いのは某QAサイトとか見ていてもよくわかるとおりです。
さすがにbugs.php.netにはそういう人はあまりいませんが、決して全くいないわけではなく、そしてそういう人の書いたバグレポは数年にわたって放置されます。

そんなわけで、注意点に気をつけつつバグレポをどんどん出しましょう。