On Fri, Dec 08, 2000 at 05:18:08PM -0000, [EMAIL PROTECTED] wrote: > wrowe 00/12/08 09:18:08 > > Modified: include apr_dbm.h > src/dbm apr_dbm.c > Log: > Document and address several problems with apr_dbm - including; > > make apr_dbm_open args sane in respect to both apr and dbm
Cool. > note absurdity of apr_dbm_freedatum in a pool-managed implementation The returned data is not always located in a pool. Specifically, GDBM's return data is malloc'd. SDBM's return data is from a shared block of memory. [hmm. sdbm's behavior should be clarified in the docs] We need a way to proactively toss GDBM's malloc'd memory. I also have a pending item to go in there and register a cleanup just in case the caller forgets to call freedatum. And no... don't suggest we copy the return data into a pool allocation. :-) > note obscurity of apr_dbm_geterror in relation to apr This isn't an issue. We have a set of error codes and strings that need to be returned to the caller. This is very similar to how we handle DSO errors. Cheers, -g -- Greg Stein, http://www.lyra.org/
