Re: Kurt's reply (Was: change submission)

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt Spanier writes:
> Hallvard,
> 
> comming back to your bug-report.
> 
> I do not see what the problem is.

Yes, I seem to have lost some context.  I think my problem simply was
that someone must verify that ldbm with Berkeley DB behaves like I
described for the other databases, before we could replace
ldbm_datum_free() with free() in various places:

  Values from ldbm_<first/next>_key should be ldbm_datum_free()'d,
  values from other ldbm_* functions should be plain free()'d.

> However, the free() is unconditional, and some calls to ldbm_datum_free()
> were not captured by appropriate tests for non-NULL pointers

(That was not my problem, I never noticed.)

> BUT, we MAY have a problem with ldbm_datum_free(), if someone uses flag
> DB_DBT_USERMEM with DB 2.x, avoiding memory allocation by DB itself,
> instead using a self-provided storage (pointed to in (Datum).dptr, with
> size in (Datum).ulen). If this storage is a static buffer, free() indeed
> may fail. However, In the DB 2.x code I provided in ldbm.c, DB_DBT_MALLOC
> together with a self-provided ldbm_malloc() function is used.

I'll take your word for it, I'm too sleepy to figure out what that means
now:-)

-- 
Hallvard