ext/standard: pathinfo() check flags argument validity.

[devnexen]

No description provided.

[nielsdos]

Interesting function with a bit of a surprising implementation, ngl.
Note that passing something like PHP_PATHINFO_DIRNAME|PHP_PATHINFO_BASENAME still is allowed but is equivalent to only passing PHP_PATHINFO_DIRNAME as a flag, which is quite bonkers. So perhaps bitwise combinations should also be blocked?

[devnexen]

well PHP_PATHINFO_ALL is itself a combination

[nielsdos]

well PHP_PATHINFO_ALL is itself a combination

Yeah but that is the only case where you get the array, so it's an exception to the rule that only one flag should be passed.

[devnexen]

yeah quite a bunch of tests to update following this.

[nielsdos]

yeah quite a bunch of tests to update following this.

Ouch. Then I wonder if this is worth it and whether Hyrum's law applies.

[devnexen]

yeah quite a bunch of tests to update following this.

and whether Hyrum's law applies.

exactly

[TimWolla]

Then I wonder if this is worth it and whether Hyrum's law applies.

It's effectively the same situation as with the php_uname() fix in PHP 8.4. I consider pointing out the “undefined behavior” to be useful, though.

[TimWolla]

This makes sense to me, but needs to be listed in UPGRADING as a backwards incompatible change, like

php-src/UPGRADING

Line 125 in fc73da5

. php_uname() now throws ValueErrors if the $move parameter is invalid.

.

[bukka]

We have already discussed changes like this in #15647 and #15883 . My suggestion was to go through the deprecations first as those are essentially BC breaks.

We really need to have some consistent strategy for this and mainly some agreement.

[bukka]

I can see that various change in pcntl got in.

Ideally we should maybe update the policy to extend a bit what kind of breaks are allowed in minor versions and what should go through the deprecations as it's currently pretty inconsistent.