Hi, what happens if there is a bug in a vendored library, but upstream refuses to fix it?
Last month, my PR for removing obsolete C99 integer checks was merged: https://github.com/php/php-src/pull/10304 This change speeds up configure and removes code that violates the C99 spec. It included a fix for ext/date/lib/ which I then learned is a vendored library; Christoph M. Becker asked me to submit the same fix upstream, which I did: https://github.com/derickr/timelib/pull/141 As you can see, the PR was closed with a comment that did not explain why. After it was pointed out to them that the existing code violates the C99 standard, they locked the PR, preventing further discussion. Not only that; they also reverted my fix in php-src, reintroducing the C99 spec violation: https://github.com/php/php-src/commit/0df92d218e88a0070fcebd5391e7 ... even though UPGRADING.INTERNALS contains an explanation that these obsolete feature macros are no longer present in PHP's config headers and should not be used. Two questions remain for me: - Should somebody with push access to php-src silently/secretly, without any discussion, revert such a fix? The revert seems to have been directly pushed to php-src without a PR and with no chance for others to review it. - In general, if a vendored library has a bug (like the C99 spec violation, or any other bug) that the upstream refuses to fix or even discuss, shall the copy in php-src be patched? Are deviations from vanilla upstream possible? Of course, this causes extra work for syncing with new upstream released, but tools like quilt could help with that. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
