Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119502 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10301 invoked from network); 9 Feb 2023 10:19:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Feb 2023 10:19:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B206718005D for ; Thu, 9 Feb 2023 02:19:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 138.201.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from swift.blarg.de (swift.blarg.de [138.201.185.127]) by php-smtp4.php.net (Postfix) with ESMTP for ; Thu, 9 Feb 2023 02:19:04 -0800 (PST) Received: from swift.blarg.de (swift.blarg.de [IPv6:2a01:4f8:c17:52a8::2]) (Authenticated sender: max) by swift.blarg.de (Postfix) with ESMTPSA id D49AB41360 for ; Thu, 9 Feb 2023 11:19:03 +0100 (CET) Date: Thu, 9 Feb 2023 11:19:02 +0100 To: internals@lists.php.net Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: How to deal with bugs in vendored libraries? From: max+php@blarg.de (Max Kellermann) 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