Re: How to deal with bugs in vendored libraries?

On 2023/02/09 16:29, Rowan Tommins <rowan.collins@gmail.com> 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