apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 06:40:46 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> 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.

View raw message