Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119509 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41995 invoked from network); 9 Feb 2023 16:05:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Feb 2023 16:05:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5B5931801FD for ; Thu, 9 Feb 2023 08:05:33 -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.5 required=5.0 tests=BAYES_05,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 08:05:32 -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 625F441360; Thu, 9 Feb 2023 17:05:31 +0100 (CET) Date: Thu, 9 Feb 2023 17:05:30 +0100 To: Rowan Tommins Cc: internals@lists.php.net Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [PHP-DEV] How to deal with bugs in vendored libraries? From: max+php@blarg.de (Max Kellermann) On 2023/02/09 16:29, Rowan Tommins wrote: > This is where I'm suggesting you assume good faith: what looks like a > "secret revert" probably feels like something entirely different to Derick. Timeline: - Jan 13 11:34 AM: PR https://github.com/derickr/timelib/pull/141/files - Jan 18 4:34 PM: PR was locked - Jan 19 7:49 PM: commit https://github.com/php/php-src/commit/0df92d218e88a0 pushed to php-src Look how the commit is exactly a revert of the timelib PR that Derick Rethans closed and locked just the day before. I'm open to hearing Derick's side of the story. > OK, that seems clear. As far as I can see, this is the first time on this > thread or either of the PR threads that you've actually explained that > violation. I explained it already: https://github.com/derickr/timelib/pull/141#issuecomment-1386800720 > OK, so follow-up question: what gives you confidence that the change is > *safe*? Sometimes, technical violations of a spec are necessary for the > practical realities of the situation. This piece of code was written when these types were not yet in the C standard (the C standard used by PHP at the time); but the code became wrong as soon as PHP switched to C99. So it's not like somebody decided "we need to violate the spec for some practical reality"; that spec didn't apply at the time. What my code change does is adjust PHP to the newly adopted C standard; this should have been part of PHP's C99 transition, but was probably forgotten. Max