On Thu, Nov 07, 2024 at 04:30:37PM -0500, Taylor Blau wrote: > > 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
