On Thu, Nov 07, 2024 at 04:30:37PM -0500, Taylor Blau wrote:

quoted

Yeah, I don't have a strong opinion one way or the other.  I think, with
the limitation I mentioned above, it would probably require a decent
amount of refactoring if we took a different approach, and I'm fine with
going with Taylor's current approach unless he wants to do that
refactoring (in which case, great).

I think it does buy you something for real code, which is that you don't
have to remember to consistently call the unsafe_ variants of all of the
various function pointers.

For instance, if you do

    the_hash_algo->unsafe_init_fn(...);

early on, and then later on by mistake write:

    the_hash_algo->update_fn(...);

Then your code is broken and will (as brian said) either in the best
case produce wrong results, or likely segfault.

Yes, true. I sort of assume that all of those calls are happening within
one function (or at least a suite of related functions). Just because
there's an implicit context of "I am computing the hash for an object"
versus "I am computing a checksum".

And if we ever do move to splitting those further (to have crc32 or
whatever for the checksum), then having a git_hash_algo for that would
seem even weirder.

-Peff