GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix

[Werner Koch]

On Sat, 21 Aug 2004 03:50:38 +0200, Bernd Eckenfels said:

> this will do a m_free on null, is that intentional? Also, I dont know the

Yes.  Unless we are somewhere deep in a loop body and want to avoid
function call, there is no need for an extra NULL check before calling
free.  Further free may be instrumented to do a consistency check on
the entire heap or a part of it even when passing NULL.  m_free is a
wrapper around free and free is defined to be a NOP for an argument of
NULL; from POSIX:

  The free ( ) function shall cause the space pointed to by ptr to be
  deallocated; that is, made available for further allocation. If ptr
  is a null pointer, no action shall occur. Otherwise, if the argument
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  does not match a pointer earlier returned by the calloc ( ), malloc
  ( ), posix_memalign ( ), realloc ( ), or strdup ( ), function, or if
  the space has been deallocated by a call to free ( ) or realloc ( ),
  the behavior is undefined.

> code around that region, but what is the sane behaviour on
> "h->locked==false" and "h->lockname!=null"?

LOCKED indicates that this process owns the lock and LOCKNAME is
merely the name of the lockfile to use.  So if LOCKED is not true we
can't unlink LOCKFILE because we don't own the lock.  

  Werner