Hi Tim! Thanks for your feedback.
> On 19.02.2026, at 09:20, Tim Düsterhus <[email protected]> wrote: > > > Thank you. I've taken a look at your RFC and from what I see it's effectively > two different proposals: > > 1. Make CRC calculations go fast with an optional external library. […] > 2. Add various CRC-64 variants. > > Adding new variants makes sense to me, particularly since the API of ext/hash > is specifically designed to be extensible in this way and since there is a > clear use case with the S3 SDK. But it makes sense to do this as an RFC to > figure out the details, particularly naming. > > One thing I'm concerned about here is that the RFC states that the new > variants are dependent on the external library to be available. ext/hash is > one of the few extensions that folks can rely on always being available, > which is very useful. I believe we should strive to not make its feature set > dependent on build time choices of PHP, because that means that frameworks, > libraries (e.g. the AWS SDK) or “off-the-shelf” applications will never be > able to rely on the algorithms being available, especially if it relies on a > specialized library being available, which will hurt adoption and increases > ecosystem fragmentation. > > I believe it is important to always provide a baseline implementation written > in pure C for this reason. I suspect it shouldn't be too complicated to add > this, since the various CRCs are generally very simple algorithms. Sorry for the confusion. I updated the relevant parts of the RFC to mention that non-HW accelerated CRC-64 implementations would always be available. I’d prefer not to split this up, unless there’s strong demand for that in further discussion. Thanks, Mike
