On Sat, Dec 09, 2000 at 09:35:26AM -0800, [EMAIL PROTECTED] wrote:
...
... [copying returned datums] ...
...
Actually, that's not true. I have added SDBM support to a couple modules
recently,
Cool! Well, I'm doubly glad, then, that we will directly export SDBM from
APRUTIL (in addition to
On Fri, Dec 08, 2000 at 04:20:17PM -0800, [EMAIL PROTECTED] wrote:
One last observation, sdbm.h does _not_ belong in apr-util/include/ and
neither
does the apu_private stuff. Suggest we move those on out of there, but
where?
apr-util/include/private? We don't need arch/
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 7:54 PM
One last observation, sdbm.h does _not_ belong in apr-util/include/ and
neither
does the apu_private stuff. Suggest we move those on out of there, but
where?
There are three locations that
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
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.
On Sat, Dec 09, 2000 at 12:50:31AM -0600, William A. Rowe, Jr. wrote:
...
So if we can agree that apr-util is a collection of many 'library' like
features,
none of which warrent a full blown library on their own, then I'm +1 to loose
the src/ layer of apr-util, and let them pick and choose
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 09, 2000 1:17 AM
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:47 PM
And no... don't suggest we copy the
On Sat, Dec 09, 2000 at 01:25:26AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 09, 2000 1:17 AM
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2000 6:37 PM
-#include apu_private.h
+#include apr_private.h
Wrong!
This is *supposed* to include apu_private.h. That is where the APU_USE_*DBM
symbols are located. I have already created an apu_private.hw
Log:
Document and address several problems with apr_dbm - including;
make apr_dbm_open args sane in respect to both apr and dbm
note absurdity of apr_dbm_freedatum in a pool-managed implementation
note obscurity of apr_dbm_geterror in relation to apr
I would