I'm upgrading code to PHP 7.4, which will now blow a notice for things
such as

null["key"]
(1.2)["key"]
(123)["key"]

All of these seem to reduce to null. (The footnote explains why I think
so.)

I have a lot of code which could be depending on such things. I'd like
to rewrite such code, but I have no idea how to find such code. I
suppose a loop such as

while ($a["key"]) { ... }

could be depending on $a sometimes being null or even being undefined
(because ``$a === null'' when $a is undefined). (These are very weird
things about PHP to my way of looking at things.)

How would you search for something like that? I just have no idea. My
best idea is to just watch a log of errors and notices and try to spot
the code that way.

(*) Footnote

I say this because of

--8<---------------cut here---------------start------------->8---
php > var_dump((123)["key"] === null);
PHP Notice: Trying to access array offset on value of type int in php
shell code on line 1

Notice: Trying to access array offset on value of type int in php shell
code on line 1
bool(true)
php >
--8<---------------cut here---------------end--------------->8---

(By the way, I don't know why I get two notices.)

Meredith Montgomery <mmontgomery@levado.to> writes:

> I'm upgrading code to PHP 7.4, which will now blow a notice for things
> such as
>
> null["key"]
> (1.2)["key"]
> (123)["key"]
>
> All of these seem to reduce to null. (The footnote explains why I think
> so.)
>
> I have a lot of code which could be depending on such things. I'd like
> to rewrite such code, but I have no idea how to find such code. I
> suppose a loop such as
>
> while ($a["key"]) { ... }
>
> could be depending on $a sometimes being null or even being undefined
> (because ``$a === null'' when $a is undefined). (These are very weird
> things about PHP to my way of looking at things.)
>
> How would you search for something like that? I just have no idea. My
> best idea is to just watch a log of errors and notices and try to spot
> the code that way.

I guess nobody had much to say here. I'm tackling easier problems at
first, but I will eventually have to come back to this and make some
decision. I suppose upgrading to PHP 7.4 and watching the a noisy log
with error_reporting = E_ALL (say) might give me more information. But,
of course, I have no way of running every line of code, so there is
really no obvious strategy for something like that.

On 30/05/2022 04.13, Meredith Montgomery wrote:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>> such as
>>
>> null["key"]
>> (1.2)["key"]
>> (123)["key"]
>>
>> All of these seem to reduce to null. (The footnote explains why I think
>> so.)
>>
>> I have a lot of code which could be depending on such things. I'd like
>> to rewrite such code, but I have no idea how to find such code. I
>> suppose a loop such as
>>
>> while ($a["key"]) { ... }

foreach
for
do ... while

finding all those cases you can use grep (generates a lot of false
positives too):
egrep "(while|for)" -r /path/to/your/scripts

This will not take care of cases where someone has assumed they get an
array and then they just need to get something from the array, for example:

$var = function_returning_array();
echo $var[0];

>> could be depending on $a sometimes being null or even being undefined
>> (because ``$a === null'' when $a is undefined). (These are very weird
>> things about PHP to my way of looking at things.)

I would suggest you to use is_array() function, in case you have
something else than just null that you get, say you would just send an
integer.

>> How would you search for something like that? I just have no idea. My
>> best idea is to just watch a log of errors and notices and try to spot
>> the code that way.

There ain't a good way to really find that, unitests had been useful,
just run those and see which ones fail, and then fix the functions tested.

> I guess nobody had much to say here. I'm tackling easier problems at
> first, but I will eventually have to come back to this and make some
> decision. I suppose upgrading to PHP 7.4 and watching the a noisy log
> with error_reporting = E_ALL (say) might give me more information. But,
> of course, I have no way of running every line of code, so there is
> really no obvious strategy for something like that.

You could take the time and write unitests now, it will make things
easier next time. One such framework for php is https://phpunit.de

As you will write tests for each function now, you will locate all the
uses of arrays.

--

//Aho

"J.O. Aho" <user@example.net> writes:

> On 30/05/2022 04.13, Meredith Montgomery wrote:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>>> such as
>>>
>>> null["key"]
>>> (1.2)["key"]
>>> (123)["key"]
>>>
>>> All of these seem to reduce to null. (The footnote explains why I think
>>> so.)
>>>
>>> I have a lot of code which could be depending on such things. I'd like
>>> to rewrite such code, but I have no idea how to find such code. I
>>> suppose a loop such as
>>>
>>> while ($a["key"]) { ... }
>
> foreach
> for
> do ... while
>
> finding all those cases you can use grep (generates a lot of false
> positives too):
> egrep "(while|for)" -r /path/to/your/scripts

Yes.

I have millions of lines of code, so I think the best approach is indeed
to just go into production with PHP 7.4 and monitor the logs so that we
catch the deprecation warnings there --- and then we act. I don't have
an army of programmers to analyze each possible loop. I need to be
practical here.

> This will not take care of cases where someone has assumed they get an
> array and then they just need to get something from the array, for
> example:
>
> $var = function_returning_array();
> echo $var[0];

Indeed.

[...]

>>> How would you search for something like that? I just have no idea. My
>>> best idea is to just watch a log of errors and notices and try to spot
>>> the code that way.
>
> There ain't a good way to really find that, unitests had been useful,
> just run those and see which ones fail, and then fix the functions
> tested.

That's what I feared, but that's life.

>> I guess nobody had much to say here. I'm tackling easier problems at
>> first, but I will eventually have to come back to this and make some
>> decision. I suppose upgrading to PHP 7.4 and watching the a noisy log
>> with error_reporting = E_ALL (say) might give me more information. But,
>> of course, I have no way of running every line of code, so there is
>> really no obvious strategy for something like that.
>
> You could take the time and write unitests now, it will make things
> easier next time. One such framework for php is https://phpunit.de
>
> As you will write tests for each function now, you will locate all the
> uses of arrays.

That's my next operation. Start writing some important unit tests that
were never written. Thank you so much for the phpunit.de
recommendation. I checked and see that the project is using SimpleTest
instead. I suppose anything reasonable is good enough for us.

Thank you for your attention.

On 2022-05-31, Meredith Montgomery <mmontgomery@levado.to> wrote:
> "J.O. Aho" <user@example.net> writes:
>
>> On 30/05/2022 04.13, Meredith Montgomery wrote:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>
>>>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>>>> such as
>>>>
>>>> null["key"]
>>>> (1.2)["key"]
>>>> (123)["key"]
>>>>
>>>> All of these seem to reduce to null. (The footnote explains why I think
>>>> so.)
>>>>
>>>> I have a lot of code which could be depending on such things. I'd like
>>>> to rewrite such code, but I have no idea how to find such code. I
>>>> suppose a loop such as
>>>>
>>>> while ($a["key"]) { ... }
>>
>> foreach
>> for
>> do ... while
>>
>> finding all those cases you can use grep (generates a lot of false
>> positives too):
>> egrep "(while|for)" -r /path/to/your/scripts
>
> Yes.
>
> I have millions of lines of code, so I think the best approach is indeed
> to just go into production with PHP 7.4 and monitor the logs so that we
> catch the deprecation warnings there --- and then we act. I don't have
> an army of programmers to analyze each possible loop. I need to be
> practical here.
>
>> This will not take care of cases where someone has assumed they get an
>> array and then they just need to get something from the array, for
>> example:
>>
>> $var = function_returning_array();
>> echo $var[0];
>
> Indeed.
>
> [...]
>
>>>> How would you search for something like that? I just have no idea. My
>>>> best idea is to just watch a log of errors and notices and try to spot
>>>> the code that way.
>>
>> There ain't a good way to really find that, unitests had been useful,
>> just run those and see which ones fail, and then fix the functions
>> tested.
>
> That's what I feared, but that's life.
>
>>> I guess nobody had much to say here. I'm tackling easier problems at
>>> first, but I will eventually have to come back to this and make some
>>> decision. I suppose upgrading to PHP 7.4 and watching the a noisy log
>>> with error_reporting = E_ALL (say) might give me more information. But,
>>> of course, I have no way of running every line of code, so there is
>>> really no obvious strategy for something like that.
>>
>> You could take the time and write unitests now, it will make things
>> easier next time. One such framework for php is https://phpunit.de
>>
>> As you will write tests for each function now, you will locate all the
>> uses of arrays.
>
> That's my next operation. Start writing some important unit tests that
> were never written. Thank you so much for the phpunit.de
> recommendation. I checked and see that the project is using SimpleTest
> instead. I suppose anything reasonable is good enough for us.
>
> Thank you for your attention.

Have you looked at PHPCompatibility?

<https://github.com/PHPCompatibility/PHPCompatibility>

--
"Though a program be but three lines long, someday it will have to be
maintained." [The Tao of Programming]

De ongekruisigde <ongekruisigde@news.eternal-september.org> writes:

> On 2022-05-31, Meredith Montgomery <mmontgomery@levado.to> wrote:
>> "J.O. Aho" <user@example.net> writes:
>>
>>> On 30/05/2022 04.13, Meredith Montgomery wrote:
>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>
>>>>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>>>>> such as
>>>>>
>>>>> null["key"]
>>>>> (1.2)["key"]
>>>>> (123)["key"]
>>>>>
>>>>> All of these seem to reduce to null. (The footnote explains why I think
>>>>> so.)
>>>>>
>>>>> I have a lot of code which could be depending on such things. I'd like
>>>>> to rewrite such code, but I have no idea how to find such code. I
>>>>> suppose a loop such as
>>>>>
>>>>> while ($a["key"]) { ... }
>>>
>>> foreach
>>> for
>>> do ... while
>>>
>>> finding all those cases you can use grep (generates a lot of false
>>> positives too):
>>> egrep "(while|for)" -r /path/to/your/scripts
>>
>> Yes.
>>
>> I have millions of lines of code, so I think the best approach is indeed
>> to just go into production with PHP 7.4 and monitor the logs so that we
>> catch the deprecation warnings there --- and then we act. I don't have
>> an army of programmers to analyze each possible loop. I need to be
>> practical here.
>>
>>> This will not take care of cases where someone has assumed they get an
>>> array and then they just need to get something from the array, for
>>> example:
>>>
>>> $var = function_returning_array();
>>> echo $var[0];
>>
>> Indeed.
>>
>> [...]
>>
>>>>> How would you search for something like that? I just have no idea. My
>>>>> best idea is to just watch a log of errors and notices and try to spot
>>>>> the code that way.
>>>
>>> There ain't a good way to really find that, unitests had been useful,
>>> just run those and see which ones fail, and then fix the functions
>>> tested.
>>
>> That's what I feared, but that's life.
>>
>>>> I guess nobody had much to say here. I'm tackling easier problems at
>>>> first, but I will eventually have to come back to this and make some
>>>> decision. I suppose upgrading to PHP 7.4 and watching the a noisy log
>>>> with error_reporting = E_ALL (say) might give me more information. But,
>>>> of course, I have no way of running every line of code, so there is
>>>> really no obvious strategy for something like that.
>>>
>>> You could take the time and write unitests now, it will make things
>>> easier next time. One such framework for php is https://phpunit.de
>>>
>>> As you will write tests for each function now, you will locate all the
>>> uses of arrays.
>>
>> That's my next operation. Start writing some important unit tests that
>> were never written. Thank you so much for the phpunit.de
>> recommendation. I checked and see that the project is using SimpleTest
>> instead. I suppose anything reasonable is good enough for us.
>>
>> Thank you for your attention.
>
> Have you looked at PHPCompatibility?
>
> <https://github.com/PHPCompatibility/PHPCompatibility>

That looks very good. I had not looked into it, but I will. I'll
report back with what I find. Thank you so much.

Meredith Montgomery <mmontgomery@levado.to> writes:

> De ongekruisigde <ongekruisigde@news.eternal-september.org> writes:
>
>> On 2022-05-31, Meredith Montgomery <mmontgomery@levado.to> wrote:
>>> "J.O. Aho" <user@example.net> writes:
>>>
>>>> On 30/05/2022 04.13, Meredith Montgomery wrote:
>>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>>
>>>>>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>>>>>> such as
>>>>>>
>>>>>> null["key"]
>>>>>> (1.2)["key"]
>>>>>> (123)["key"]

[...]

>> Have you looked at PHPCompatibility?
>>
>> <https://github.com/PHPCompatibility/PHPCompatibility>
>
> That looks very good. I had not looked into it, but I will. I'll
> report back with what I find. Thank you so much.

Thank you for the suggestion. My sane tests all worked, but now I'm
processing an entire directory structure and the program seems to be
quitting at 15%, returning exit code 255.

$ phpcs -p . --standard=PHPCompatibility
............................................................. 60 / 12472 (0%)
.............WWWWWW.....W.................................... 120 / 12472 (1%)
............................................................. 180 / 12472 (1%)
..........................................................W.. 240 / 12472 (2%)
............................................................. 300 / 12472 (2%)
....................W........................................ 360 / 12472 (3%)
................W....................W....................... 420 / 12472 (3%)
W........................................................... 480 / 12472 (4%)
W..........W.W..........W...........W....................... 540 / 12472 (4%)
.......................W.........W...WW.W...W....W.......W... 600 / 12472 (5%)
.......W.WW...W..WWWW....W.........W.W.W.W..WW.W.WWWWW.WWEWWW 660 / 12472 (5%)
WWWWWWWWWWWWW.WW...W.WWWWWW.WW.WWWW...WW.WWE...........W.... 720 / 12472 (6%)
EEWW..E..................................................... 780 / 12472 (6%)
....................W........................................ 840 / 12472 (7%)
............................................................. 900 / 12472 (7%)
....................W........................................ 960 / 12472 (8%)
..........................................W.................. 1020 / 12472 (8%)
.....................................W....................... 1080 / 12472 (9%)
........................W........................W........W.. 1140 / 12472 (9%)
WW............W..........W.W...W...............W....W....... 1200 / 12472 (10%)
.......W..................................................... 1260 / 12472 (10%)
............................................................. 1320 / 12472 (11%)
............................................................. 1380 / 12472 (11%)
....................W......WWWW....W.W........W....W......... 1440 / 12472 (12%)
..........................................................W.. 1500 / 12472 (12%)
WWWWW..W...W..............WW.WWW......W........W............ 1560 / 12472 (13%)
........W...................................SS..S..S......... 1620 / 12472 (13%)
..........SS...............................................SS 1680 / 12472 (13%)
S...S.S......S.............................................. 1740 / 12472 (14%)
...S...........S...............................S............. 1800 / 12472 (14%)
............................................................. 1860 / 12472 (15%)
...................SS............S.S...SSSS............S..S.S 1920 / 12472 (15%)
...$ echo $?
255
$

(*) A new attempt

If I use the --report-file flag, I get to see the partial report
produced, so I have 15% of the full report, but the program seems to
quit (or crash) like before.

$ phpcs -p . --standard=PHPCompatibility --report-file=/usr/local/tmp/report.txt
[...]
...................SS............S.S...SSSS............S..S.S 1920 / 12472 (15%)
...$ echo $?
255

I have not yet found any debugging flags or anything like that.

On 2022-06-03, Meredith Montgomery <mmontgomery@levado.to> wrote:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> De ongekruisigde <ongekruisigde@news.eternal-september.org> writes:
>>
>>> On 2022-05-31, Meredith Montgomery <mmontgomery@levado.to> wrote:
>>>> "J.O. Aho" <user@example.net> writes:
>>>>
>>>>> On 30/05/2022 04.13, Meredith Montgomery wrote:
>>>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>>>
>>>>>>> I'm upgrading code to PHP 7.4, which will now blow a notice for things
>>>>>>> such as
>>>>>>>
>>>>>>> null["key"]
>>>>>>> (1.2)["key"]
>>>>>>> (123)["key"]
>
> [...]
>
>>> Have you looked at PHPCompatibility?
>>>
>>> <https://github.com/PHPCompatibility/PHPCompatibility>
>>
>> That looks very good. I had not looked into it, but I will. I'll
>> report back with what I find. Thank you so much.
>
> Thank you for the suggestion. My sane tests all worked, but now I'm
> processing an entire directory structure and the program seems to be
> quitting at 15%, returning exit code 255.
>
> $ phpcs -p . --standard=PHPCompatibility
> ............................................................ 60 / 12472 (0%)
> ............WWWWWW.....W.................................... 120 / 12472 (1%)
> ............................................................ 180 / 12472 (1%)
> .........................................................W.. 240 / 12472 (2%)
> ............................................................ 300 / 12472 (2%)
> ...................W........................................ 360 / 12472 (3%)
> ...............W....................W....................... 420 / 12472 (3%)
> W........................................................... 480 / 12472 (4%)
> W..........W.W..........W...........W....................... 540 / 12472 (4%)
> ......................W.........W...WW.W...W....W.......W... 600 / 12472 (5%)
> ......W.WW...W..WWWW....W.........W.W.W.W..WW.W.WWWWW.WWEWWW 660 / 12472 (5%)
> WWWWWWWWWWWWW.WW...W.WWWWWW.WW.WWWW...WW.WWE...........W.... 720 / 12472 (6%)
> EEWW..E..................................................... 780 / 12472 (6%)
> ...................W........................................ 840 / 12472 (7%)
> ............................................................ 900 / 12472 (7%)
> ...................W........................................ 960 / 12472 (8%)
> .........................................W.................. 1020 / 12472 (8%)
> ....................................W....................... 1080 / 12472 (9%)
> .......................W........................W........W.. 1140 / 12472 (9%)
> WW............W..........W.W...W...............W....W....... 1200 / 12472 (10%)
> ......W..................................................... 1260 / 12472 (10%)
> ............................................................ 1320 / 12472 (11%)
> ............................................................ 1380 / 12472 (11%)
> ...................W......WWWW....W.W........W....W......... 1440 / 12472 (12%)
> .........................................................W.. 1500 / 12472 (12%)
> WWWWW..W...W..............WW.WWW......W........W............ 1560 / 12472 (13%)
> .......W...................................SS..S..S......... 1620 / 12472 (13%)
> .........SS...............................................SS 1680 / 12472 (13%)
> S...S.S......S.............................................. 1740 / 12472 (14%)
> ..S...........S...............................S............. 1800 / 12472 (14%)
> ............................................................ 1860 / 12472 (15%)
> ..................SS............S.S...SSSS............S..S.S 1920 / 12472 (15%)
> ..$ echo $?
> 255
> $
>
> (*) A new attempt
>
> If I use the --report-file flag, I get to see the partial report
> produced, so I have 15% of the full report, but the program seems to
> quit (or crash) like before.
>
> $ phpcs -p . --standard=PHPCompatibility --report-file=/usr/local/tmp/report.txt
> [...]
> ..................SS............S.S...SSSS............S..S.S 1920 / 12472 (15%)
> ..$ echo $?
> 255
>
> I have not yet found any debugging flags or anything like that.

Looks like your code base is too big for PHPCompatibility. Can you split
it up somehow and call the program on the parts? It's probably not one
monolithic whole, where everything calls everything?

--
lisp, v.:
To call a spade a thpade.