Remove old zend_string compatibility aliases

[DanielEScherzer]

No description provided.

[DanielEScherzer]

CC @iluuu1994, this was the motivation behind #19033

[iluuu1994]

This may break some extensions, and IMO adds little value. It may be enough to just mark them with a deprecated comment. But I don't object if others agree with dropping.

[DanielEScherzer]

These have been aliases since 4bd22cf, i.e. since PHP 7.0.0 - are there any extensions that still try to support PHP 5.6?

[iluuu1994]

Extensions that still use the old macros will have to switch to the new ones, even though they do the same thing. It's not a huge problem, there aren't that many extensions, but it seems like unnecessary friction.

[DanielEScherzer]

Did some github searches (code being in c, excluding forks) - in the results a bunch of hits seem like forks that aren't forked on GitHub, i.e. copies of php-src

• IS_INTERNED() has 716 hits (https://github.com/search?q=%2F%28%3F-i%29%5CbIS_INTERNED%5C%28%2F+lang%3Ac+-is%3Afork&type=code&p=2)
• STR_EMPTY_ALLOC() has 764 hits (https://github.com/search?q=%2F%28%3F-i%29%5CbSTR_EMPTY_ALLOC%5C%28%2F+lang%3Ac+-is%3Afork&type=code)
• _STR_HEADER_SIZE has 65 hits (https://github.com/search?q=%2F%28%3F-i%29%5Cb_STR_HEADER_SIZE%2F+lang%3Ac+-is%3Afork&type=code)
• STR_ALLOCA_ALLOC() has 59 (https://github.com/search?q=%2F%28%3F-i%29%5CbSTR_ALLOCA_ALLOC%5C%28%2F+lang%3Ac+-is%3Afork&type=code)
• STR_ALLOCA_INIT() has 52 (https://github.com/search?q=%2F%28%3F-i%29%5CbSTR_ALLOCA_INIT%5C%28%2F+lang%3Ac+-is%3Afork&type=code)
• STR_ALLOCA_FREE() has 60 (https://github.com/search?q=%2F%28%3F-i%29%5CbSTR_ALLOCA_FREE%5C%28%2F+lang%3Ac+-is%3Afork&type=code)

If you exclude -path:Zend/ -path:zend_string.h, the hits drop

• IS_INTERNED() 716 -> 352
• STR_EMPTY_ALLOC() 764 -> 470
• _STR_HEADER_SIZE 65 -> 15
• STR_ALLOCA_ALLOC() 59 -> 7
• STR_ALLOCA_INIT() 52 -> 1
• STR_ALLOCA_FREE() 60 -> 7

[iluuu1994]

@DanielEScherzer It may exclude too much, but -path:Zend/ may help.

[TimWolla]

I'm in favor of cleaning up this kind of legacy API, due to the DX improvements. As an example, it will make IDE autocompletion more useful.

Similarly to userland code, external extensions will also need to be checked for each new PHP version to make sure they integrate well (even if it builds, it doesn't mean that it's working well), updating to the latest API provided by PHP (especially when latest means PHP 7.0+) is a reasonable expectation.

In fact, I would be in favor of even more aggressive internal cleanups to improve maintainability and onboarding of new core developers. For this kind of cleanup we could provide official Coccinelle patches to allow external consumers to easily make the same changes.