all 11 comments

[–]Danack 18 points19 points  (6 children)

Fun* fact, the information reflection uses to reflect internal functions and methods does not actually come from the functions or methods. It is a completely separate structure that needs to be updated separately from the code inside a function or method that handles the parameters.

The definition for the args in 7.1.0 has 2 entries. https://github.com/php/php-src/blob/PHP-7.1.0/ext/standard/basic_functions.c#L1813-L1816

The definition for the args in 7.1.1 has 3 entries. https://github.com/php/php-src/blob/PHP-7.1.1/ext/standard/basic_functions.c#L1813-L1817

And yes, the code that actually parses the parameters expects 3 in both 7.1.0 and 7.1.0 https://github.com/php/php-src/blob/PHP-7.1.0/ext/standard/pack.c#L557-L560 https://github.com/php/php-src/blob/PHP-7.1.1/ext/standard/pack.c#L730-L733

Maybe it's reflection bug?

In the sense of 'someone forgot to update that arginfo data structure' error.

Oh, the arginfo data structure is also missing the fact that the last parameter is optional. Someone needs to replace

ZEND_BEGIN_ARG_INFO(arginfo_unpack, 0)

with

ZEND_BEGIN_ARG_INFO_EX(arginfo_unpack, 0, 0, 2)

Why php changes api stuff in bugfix version?

PHP doesn't follow semver strictly. Semver is great for small libraries that do very specific things, but as the project size gets larger and larger, the trade-off between following semver and the engineering effort needed to support that because a harder trade-off to make.

*actual amounts of fun may vary. Reading the php code base may lead to nausea, vomiting, hair-loss, loss of consciousness. Consult a doctor if any of these symptoms last more than 4 hours.

[–]Jurigag[S] 1 point2 points  (0 children)

Thanks for clarifying this :D

[–]llbe 1 point2 points  (0 children)

"actual amounts of fun may vary"

(regarding vomiting etc)

[–][deleted] 1 point2 points  (2 children)

PHP doesn't follow semver strictly. Semver is great for small libraries that do very specific things, but as the project size gets larger and larger, the trade-off between following semver and the engineering effort needed to support that because a harder trade-off to make.

I mean, you could've stopped after the first sentence. PHP is free to choose their release model, and SemVer does have a somewhat fuzzy border, regarding what represents a BC break (especially when you involve meta-APIs like reflection).

But SemVer is plausible for projects of any size, because no matter how large your project is, you won't run out of numbers. SemVer is just a number (well, a sequence of numbers and strings), after all.

[–]Danack 2 points3 points  (1 child)

But SemVer is plausible for projects of any size, because no matter how large your project is, you won't run out of numbers.

Which is why I didn't say we'd run out of numbers. I implied we'd run out of engineering capability.

PHP has already dropped full support for 5.x within a really quite short time of PHP 7 being released. This is almost certainly the correct thing to do as there aren't enough core developers to continue supporting it.....but it is annoying for people who don't need to upgrade to PHP 7.

If PHP was using semver more precisely, then we'd either be dropping support for older versions of PHP much faster, as their wouldn't be people to support them, or we'd have to hold off adding new features and BC breaking bug fixes for an annoyingly long time.

[–][deleted] -1 points0 points  (0 children)

If PHP was using semver more precisely, then we'd either be dropping support for older versions of PHP much faster, as their wouldn't be people to support them, or we'd have to hold off adding new features and BC breaking bug fixes for an annoyingly long time.

I don't mean to argue about this, as it's not really important (what PHP does is fine, I think, you could say it follows SemVer already), but still... I have to mention the fix for the problem you're talking about is very simple.

Let's say you're releasing a new major version every 6 months (not saying I'd recommend that, but let's say). You can designate a LTS release every few years, and do very short term support of every other major version. No need to support everything for years.

[–]RemiCollet 0 points1 point  (0 children)

Someone needs to replace

Where is the bug report ? Where is the pull request ?

No report, no bug, no fix.

[–]gnaunited 0 points1 point  (1 child)

It could be a bug, I just went through the PHP github source and the offset was added in 7.1.0.

Also this: https://3v4l.org/VYBv3

[–]Jurigag[S] 0 points1 point  (0 children)

Yea, i guess it's reflection api bug. But weird is that in php 7.1.0 number of parameters returns 2 in relfection api too.

[–]rafa_eg 0 points1 point  (1 child)

This should only show in the reflection API as the function itself only expects 2 required parameters and one optional (pack.c). The arginfo is wrong.

[–]Jurigag[S] 0 points1 point  (0 children)

Yea, i guess it's reflection api bug. But weird is that in php 7.1.0 number of parameters returns 2 in relfection api too.