On 2026-07-03 at 11:27:36, Patrick Steinhardt wrote:
> On Thu, Jul 02, 2026 at 04:07:07AM -0400, Jeff King wrote:
> > The flag handling could be removed if the hash-discard function were
> > idempotent. This could be done easily-ish by having the underlying
> > hash functions (like the ones in sha256/openssl.h) set the context
> > pointer to NULL after free-ing. But it's something that every platform
> > implementation would have to remember to do, and the benefit for the
> > callers is not that huge (it would let us shave a few lines here and
> > probably in a few other spots).
> 
> This answers an earlier question of mine. It would indeed be great if it
> was idempotent -- I've been bitten by interfaces like this once too
> much, where you have to be very careful to manage the lifetime of a
> specific object. The prime example of this are (were? I don't quite
> recall whether we fixed that interface) reference transactions, and that
> caused a bunch of bugs in the past.

Yes, that would be fantastic.  The Rust code will need a few fixes as
well (which I will send on top of this one when it's picked up) and it
really simplifies our Drop implementation if I can just do
`git_hash_discard`.  Otherwise, I need to keep track of whether we've
already called one of the final functions or not to avoid a double free.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA