Greg Stein <[EMAIL PROTECTED]> writes:
> Different? In terms of the destroy function? You're right (as I just
> posted). I don't think transient should be using free().
>
> The two buckets are the same except for transient behavior.
Oops... Sorry for the bogus commit message. I had such a time
On Wed, Feb 28, 2001 at 03:43:45PM -0800, [EMAIL PROTECTED] wrote:
>
> This is a definate bug. Neither of these bucket types should call free.
> Please commit this ASAP. I would bet this is the cause of our corruption
> on Apache.org.
Only if you built apache.org's server in the last 24 hours.
Different? In terms of the destroy function? You're right (as I just
posted). I don't think transient should be using free().
The two buckets are the same except for transient behavior.
Cheers,
-g
On Wed, Feb 28, 2001 at 06:37:05PM -0500, Jeff Trawick wrote:
> For an immortal bucket, the data is
This is a definate bug. Neither of these bucket types should call free.
Please commit this ASAP. I would bet this is the cause of our corruption
on Apache.org.
Ryan
On Wed, 28 Feb 2001, Jeff Trawick wrote:
> For an immortal bucket, the data is typically a non-writeable string.
> But we do a f
For an immortal bucket, the data is typically a non-writeable string.
But we do a free() on it when we get rid of the bucket representing
it. This seems obviously broken
Why is transient any different in this respect? The bucket code
doesn't know where the data lives (other than knowing that it
On Wed, Feb 28, 2001 at 03:03:08PM -0500, Cliff Woolley wrote:
>...
> Basically, instead of having the pool bucket contain a pointer to a heap
> bucket and having to fool with manipulating reference counts and keeping
> track of when to destroy the old apr_bucket_pool struct, the
> apr_bucket_pool
Oversight on my part. We specified the symbol name in configure.in, so I
slapped the APR_ prefix on there. (the HAVE_ symbols come from autoconf, so
we can't do much about it)
How about APR_USING_OLD_EXPAT? I'm not comfy with the APR_HAS_ approach
because we aren't advertising the symbol, so we ar
On Wed, Feb 28, 2001 at 02:46:32PM -0500, Jeff Trawick wrote:
> Jim Jagielski <[EMAIL PROTECTED]> writes:
>
> > According to the autoconf docs:
> >
> >Autoconf requires GNU `m4' in order to generate the scripts. It
> >uses features that some UNIX versions of `m4' do not have. It also
>
On Wed, Feb 28, 2001 at 05:52:49PM -, [EMAIL PROTECTED] wrote:
> jwoolley01/02/28 09:52:48
>
> Modified:.CHANGES
>buckets apr_buckets_file.c apr_buckets_heap.c
> apr_buckets_mmap.c apr_buckets_pool.c
> apr_bucke
On Wed, Feb 28, 2001 at 11:46:39AM -0500, Cliff Woolley wrote:
>...
> HUGE_STRING_LEN comes from apr_lib.h, not from within aprutil, and other
> parts of APR (and maybe Apache, too) are using it. It ought to be
> namespace protected (APR_HUGE_STRING_LEN) (don't I remember past
> discussion about t
On Wed, Feb 28, 2001 at 02:51:13PM -0600, Sam TH wrote:
> On Wed, Feb 28, 2001 at 02:41:32PM -, [EMAIL PROTECTED] wrote:
> > Local changes and modifications were applied. See README.APRUTIL
>
> And where might one find such a file?
I haven't written it yet :-)
I just wanted that comment in
On Wed, Feb 28, 2001 at 02:16:20PM -0500, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
> > gstein 01/02/28 07:18:37
> >
> > Modified:.buildconf.sh
> >buildapu-conf.m4
> > Log:
>...
> > *) invoke expat's configuration when APRUTIL is configured
>...
> I
On Wed, Feb 28, 2001 at 09:49:09AM -0600, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 28, 2001 9:14 AM
>
>
> > gstein 01/02/28 07:14:50
> >
> > Modified:xml apr_xml.c
> > Log:
> > enable building against old/new expats
> >
> > Revi
On Wed, Feb 28, 2001 at 11:00:00AM -0600, William A. Rowe, Jr. wrote:
> > wrowe 01/02/28 08:58:35
> >
> > Modified:xml apr_xml.c
> > Log:
> > Just trying to keep Win32 semi-buildable
>
> I'll be rid of the crufty hack this eve, and incorporate the new expat so the
> srclib
On Wed, Feb 28, 2001 at 02:41:32PM -, [EMAIL PROTECTED] wrote:
> Local changes and modifications were applied. See README.APRUTIL
And where might one find such a file?
sam th
[EMAIL PROTECTED]
http://www.abisource.com/~sam/
GnuPG Key
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
> pass the right value to free() to prevent segfaults and corrupted
> heaps and other nasties
Ugghghhh... damn me. I'm just causing all sorts of problems, aren't I?
--Cliff
On Tue, 27 Feb 2001, Greg Stein wrote:
> Euh... I don't think we want another ring.
>
> A simpler idea is to have the apr_bucket_pool structure contain a pointer to
> an apr_bucket_heap structure. At cleanup time, you do the following:
...
> So what you get here is a single allocation of a heap bu
Jim Jagielski <[EMAIL PROTECTED]> writes:
> According to the autoconf docs:
>
>Autoconf requires GNU `m4' in order to generate the scripts. It
>uses features that some UNIX versions of `m4' do not have. It also
>overflows internal limits of some versions of `m4', including GNU `m4'
[EMAIL PROTECTED] writes:
> gstein 01/02/28 07:18:37
>
> Modified:.buildconf.sh
>buildapu-conf.m4
> Log:
> *) buildconf.sh should invoke expat's buildconf.sh, if it exists
> *) expat.h.in is a more reliable test for an Expat distribution
> *) look fo
> wrowe 01/02/28 08:58:35
>
> Modified:xml apr_xml.c
> Log:
> Just trying to keep Win32 semi-buildable
I'll be rid of the crufty hack this eve, and incorporate the new expat so the
srclib/
copy can be nuked late tonight/early tommorow. BTW... don't we already have an
apr
On Wed, 28 Feb 2001 [EMAIL PROTECTED] wrote:
> I like making APR_BUCKET_BUFF_SIZE == 8192 [and using it]
Okay, I'll do that.
> and removing the other.
HUGE_STRING_LEN comes from apr_lib.h, not from within aprutil, and other
parts of APR (and maybe Apache, too) are using it. It ought to be
name
Greg... looking at your new apr_xml.c
#ifdef APR_HAVE_OLD_EXPAT
#include "xmlparse.h"
#else
#include "expat.h"
#endif
Can we all agree that APR_HAVE_FOO is _ALWAYS_ defined in terms of a boolean?
The reason I broke so much code was grepping for APR_HAVE_ and HAVE_,
expecting
the forme
> So... that is the design we happen to be using in Apache, and is emboded in
> the various APR and APRUTIL bits. It might be interesting to determine
> whether a similar design would work for Samba's needs.
samba is an incredibly large monolith. it is a combination of twelve to
fifteen separate
On Wed, 28 Feb 2001, Cliff Woolley wrote:
> On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>
> >buf = malloc(APR_BUCKET_BUFF_SIZE);
> >b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0,
> > NULL);
>
> On a side note, we currently have two macros that do almost the s
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>buf = malloc(APR_BUCKET_BUFF_SIZE);
>b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
On a side note, we currently have two macros that do almost the same
thing: APR_BUCKET_BUFF_SIZE (=9000) which determines t
From: <[EMAIL PROTECTED]>
Sent: Wednesday, February 28, 2001 9:14 AM
> gstein 01/02/28 07:14:50
>
> Modified:xml apr_xml.c
> Log:
> enable building against old/new expats
>
> Revision ChangesPath
> 1.18 +6 -3 apr-util/xml/apr_xml.c
> +#include "apu_co
On Wed, Feb 28, 2001 at 11:47:26AM +0100, Sander Striker wrote:
> Hi,
>
> Before I start throwing stuff at you, I'll introduce myself.
> I'm Sander Striker, one of the Samba TNG team members. We have
> been looking at the APR a bit to find out if we can use it in
> our code.
Hi! :-)
>...
> Below
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>buf = malloc(APR_BUCKET_BUFF_SIZE);
>b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
>APR_BRIGADE_INSERT_TAIL(bb, b);
> +b->length = 0; /* We are writing into the brigade, and
>
On Wed, Feb 28, 2001 at 02:41:32PM -, [EMAIL PROTECTED] wrote:
> gstein 01/02/28 06:41:32
>
> Added: xml/expat .cvsignore Makefile.in README acconfig.h
> buildconf.sh configure.in
>xml/expat/conftools .cvsignore PrintPath install-sh missing
On Wed, Feb 28, 2001 at 11:40:21AM +, Ben Laurie wrote:
> [EMAIL PROTECTED] wrote:
> >
> > trawick 01/02/27 18:19:02
> >
> > Modified:buckets apr_buckets_simple.c
> > Log:
> > Fix some warnings related to the fact that you can't do arithmetic
> > with a void *.
>
> Wouldn't
[EMAIL PROTECTED] wrote:
>
> trawick 01/02/27 18:19:02
>
> Modified:buckets apr_buckets_simple.c
> Log:
> Fix some warnings related to the fact that you can't do arithmetic
> with a void *.
Wouldn't it be better to make b->data a char * in the first place?
Cheers,
Ben.
>
>
Cliff Woolley wrote:
>
> On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>
> > Fix some warnings related to the fact that you can't do arithmetic
> > with a void *.
>
> Oops, sorry about that. Didn't get the warning on my Linux box. Thanks
> for the fix.
>
> --Cliff
These warning were errors on
Hi,
Before I start throwing stuff at you, I'll introduce myself.
I'm Sander Striker, one of the Samba TNG team members. We have
been looking at the APR a bit to find out if we can use it in
our code.
It looks all very promissing and that's why we want to contribute
some ideas to (from our point o
It's a bit moot now :-) .. but yah: they can/should be tossed. Good eye.
Cheers,
-g
On Tue, Feb 27, 2001 at 10:18:56PM -0500, Cliff Woolley wrote:
>
> Why do we need an array of all the bucket types, and therefore
> apr_bucket_init_types() and apr_bucket_insert_type()? I seem to recall
> that t
On Tue, 27 Feb 2001, Cliff Woolley wrote:
> Nothing uses the array that gets built. Can anyone think of a reason
> I shouldn't delete the array and these two functions?
Alright, they're going away. apr_bucket_insert_type() doesn't even work
right. (The second assignment should be to *newone, n
Why do we need an array of all the bucket types, and therefore
apr_bucket_init_types() and apr_bucket_insert_type()? I seem to recall
that this was necessary in the very early days of the bucket API. But I
can't see any reason to keep them anymore. (The error bucket gets by
without registering
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
> Fix some warnings related to the fact that you can't do arithmetic
> with a void *.
Oops, sorry about that. Didn't get the warning on my Linux box. Thanks
for the fix.
--Cliff
On 27 Feb 2001, Jeff Trawick wrote:
> Ian Holsman <[EMAIL PROTECTED]> writes:
>
> > Failing on Solaris 2.7 box
>
> The sigwait() problem got fixed Sunday... I don't think APR is
> building on Solaris right now though.
It builds on Solaris 2.6 (just tried it), though with a few warnings:
--Cliff
On Tue, 27 Feb 2001, Jim Jagielski wrote:
| According to the autoconf docs:
|
|Autoconf requires GNU `m4' in order to generate the scripts. It
|uses features that some UNIX versions of `m4' do not have. It also
|overflows internal limits of some versions of `m4', including GNU `m4'
According to the autoconf docs:
Autoconf requires GNU `m4' in order to generate the scripts. It
uses features that some UNIX versions of `m4' do not have. It also
overflows internal limits of some versions of `m4', including GNU `m4'
1.0. You must use version 1.1 or later of GNU `m4
40 matches
Mail list logo
