BC in php_uname() from 8.3 to 8.4-RC1

[that-guy-iain]

Description

The following code

<?php
$platformStr = php_uname('s r v m');

Resulted in this output:

  #message: "php_uname(): Argument #1 ($mode) must be a single character"

But I expected this output instead:

No error 

PHP Version

PHP 8.4-RC1

Operating System

Ubuntu 22.04

[damianwadley]

What's your expected output? The uname for the first character, s? Because that's all PHP would ever return.
https://3v4l.org/l60Xo

So the error is now pointing out a bug in the code. And the change is present in the appropriate files so that the documentation will be updated to mention the bug fix.
https://github.com/php/php-src/pull/15385/files

[that-guy-iain]

My expected outcome is no error. This is code is being used by a third-party library to identify PHP version usages. I personally, don't care about it or use it. But I do care that my code broke because of a breaking change that isn't mentioned in the documentation as php_uname('s r v m'); style mode is mentioned on the documentation page.

'a': This is the default. Contains all modes in the sequence "s n r v m"

[jimwins]

Elevating this from a silent failure to an explicit error just hadn't been added to the documentation yet. php/doc-en#3968

php_uname() has been documented as only taking a single character for $mode for twenty years.

php/doc-en@d34c952

[damianwadley]

My expected outcome is no error.

Obviously. I was thinking more like "The expected behavior is that calling php_uname() with the string s n r v m, as mentioned in the documentation, would return a string with those five values inserted into it, similar to how date() works with date and time formatting placeholders." Which makes sense... except that the function has never worked that way, and it returns anything at all (by only using the first character in the string) due to a quirk of the implementation.

Fact is, php_uname("s n r v m") does not work and has never worked. If anything, it being an error with PHP 8.4 has had the unexpected benefit of pointing out that the code was incorrect.

a breaking change that isn't mentioned in the documentation

PHP 8.4 hasn't released yet.

[that-guy-iain]

Elevating this from a silent failure to an explicit error just hadn't been added to the documentation yet. php/doc-en#3968

Let's not act like is only because I noticed the breaking change. Months later a PR is opened. As I said, in the pr you created quietly changing docs is even worse than haphazardly adding breaking changes.

Fact is, php_uname("s n r v m") does not work and has never worked. If anything, it being an error with PHP 8.4 has had the unexpected benefit of pointing out that the code was incorrect.

Breaking people's code for no other benefit is not a benefit. It should not be needed to be pointed out the importance of backwards compatibility on a project of this scale, yet here we are. PHP has a terrible reputation quite simply because of cowboy antics like this from decades ago where people would just go change stuff without any thought of others. There are RFCs for other issues like this but not this one.

There are tons of bugs in PHP which are valid and annoy the hell out of people but are left there because backwards compatibility. But here we are with simple code that is implied to work on the documentation no longer working and the breaking change not being removed, why? What is the benefit is there to break other people's code with this change? It should not be needed to be pointed out that you should only inconvenience others to when you're adding benefits and not when there are just cons.

Sorry if this seems abrasive but the absolute nonsense that goes on in this industry and the amount of work others are willing to make others do to save fixing an issue they created pisses me off. As it reads here, you don't care if it'll cause others problems.

[alecpl]

You might argue that a proper fix should have been to support such input and treat it as a format string.

Imo, this at least should be changed to a deprecation warning in 8.4.

[cmb69]

As PHP developer, I'm in favor of having the engine telling me that I'm doing something what may not work as expected. As php-src developer, I'm in favor of being able to understand that only taking the first character of the string into account is not an oversight, but a deliberate design decision.

That said, I agree that the change may be too drastic, and that we should reconsider to downgrade to a deprecation notice for now. @Girgias, what do you think?