> From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Friday, December 08, 2000 5:47 PM > > > 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]
Of course not, but it should be. > 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. :-) I'm suggesting exactly that. That, or the entire concept of a 'pool dbm' is bogus, as rbb keeps trying to assert. I don't agree, but if we are only taking this half way, then we are going in the wrong direction. > > 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. similar != same and it is even more likely to cause confusion. all our apr_err anything functions all copy an error message to the _user's_ own char* buffer. apr_dbm_geterror should do the same.
