You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/02/13 19:25:31 UTC
docco problem (was RE: Chunk filter problem?)
> -----Original Message-----
> Okay, I'm not 100% sure on this, but I think I spotted a problem in the
> chunk filter such that two immortal buckets are getting inserted AFTER the
> EOS bucket by means of transposed parameters to the
> APR_BUCKET_INSERT_BEFORE macro.
Okay, I had it the wrong way around, thankfully. It's the documentation
that's got it wrong, not the chunk filter. So nix the chunk filter patch,
as it's incorrect. Instead, we just need to change the docco in
apr_buckets.h in APR-UTIL to reflect reality:
Index: apr_buckets.h
===================================================================
RCS file: /home/cvspublic/apr-util/include/apr_buckets.h,v
retrieving revision 1.73
diff -u -r1.73 apr_buckets.h
--- apr_buckets.h 2001/02/11 15:50:10 1.73
+++ apr_buckets.h 2001/02/13 18:21:46
@@ -338,16 +338,16 @@
/**
* Insert a list of buckets before a specified bucket
- * @param a The buckets to insert
- * @param b The bucket to insert before
+ * @param a The bucket to insert before
+ * @param b The buckets to be inserted
* @deffunc void APR_BUCKET_INSERT_BEFORE(apr_bucket *a, apr_bucket *b)
*/
#define APR_BUCKET_INSERT_BEFORE(a, b) \
APR_RING_INSERT_BEFORE((a), (b), link)
/**
* Insert a list of buckets after a specified bucket
- * @param a The buckets to insert
- * @param b The bucket to insert after
+ * @param a The bucket to insert after
+ * @param b The buckets to be inserted
* @deffunc void APR_BUCKET_INSERT_AFTER(apr_bucket *a, apr_bucket *b)
*/
#define APR_BUCKET_INSERT_AFTER(a, b) \
It'd be really nice if the ring macros were documented, as that would have
cleared up this confusion pretty quickly (as it was, I had to trace through
the ring macros on a whiteboard to make absolutely sure of which way around
they were supposed to go). I don't suppose anyone would object if I
documented them? =-)
--Cliff
Re: docco problem (was RE: Chunk filter problem?)
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Cliff Woolley wrote:
>
> > Didn't you say that mod_include used them the other direction? Does this
> > mean that mod_include is now wrong?
>
> I said that I thought it was, yeah, but that was after only a very brief
> inspection. It turns out that it's just playing tricky games, I think. I'm
> still trying to digest mod_include. =-) But anyway, if they were
> backwards, we'd be seeing scrambled web pages and other very wacky behavior.
> Somebody who knows mod_include better than I do could verify this if they
> had a second...
I'm looking into this now...
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
RE: docco problem (was RE: Chunk filter problem?)
Posted by Cliff Woolley <cl...@yahoo.com>.
> Didn't you say that mod_include used them the other direction? Does this
> mean that mod_include is now wrong?
I said that I thought it was, yeah, but that was after only a very brief
inspection. It turns out that it's just playing tricky games, I think. I'm
still trying to digest mod_include. =-) But anyway, if they were
backwards, we'd be seeing scrambled web pages and other very wacky behavior.
Somebody who knows mod_include better than I do could verify this if they
had a second...
> > I don't suppose anyone would object if I documented [the ring macros]?
=-)
> Heh... no :-)
I didn't think so. ;-] It's on my short list.
--Cliff
---------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
804-244-8615
Charlottesville, VA
RE: docco problem (was RE: Chunk filter problem?)
Posted by Cliff Woolley <cl...@yahoo.com>.
> Didn't you say that mod_include used them the other direction? Does this
> mean that mod_include is now wrong?
I said that I thought it was, yeah, but that was after only a very brief
inspection. It turns out that it's just playing tricky games, I think. I'm
still trying to digest mod_include. =-) But anyway, if they were
backwards, we'd be seeing scrambled web pages and other very wacky behavior.
Somebody who knows mod_include better than I do could verify this if they
had a second...
> > I don't suppose anyone would object if I documented [the ring macros]?
=-)
> Heh... no :-)
I didn't think so. ;-] It's on my short list.
--Cliff
---------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
804-244-8615
Charlottesville, VA
Re: docco problem (was RE: Chunk filter problem?)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:25:31PM -0500, Cliff Woolley wrote:
>
> > -----Original Message-----
> > Okay, I'm not 100% sure on this, but I think I spotted a problem in the
> > chunk filter such that two immortal buckets are getting inserted AFTER the
> > EOS bucket by means of transposed parameters to the
> > APR_BUCKET_INSERT_BEFORE macro.
>
> Okay, I had it the wrong way around, thankfully. It's the documentation
> that's got it wrong, not the chunk filter. So nix the chunk filter patch,
> as it's incorrect. Instead, we just need to change the docco in
> apr_buckets.h in APR-UTIL to reflect reality:
Didn't you say that mod_include used them the other direction? Does this
mean that mod_include is now wrong?
> It'd be really nice if the ring macros were documented, as that would have
> cleared up this confusion pretty quickly (as it was, I had to trace through
> the ring macros on a whiteboard to make absolutely sure of which way around
> they were supposed to go). I don't suppose anyone would object if I
> documented them? =-)
Heh... no :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: docco problem (was RE: Chunk filter problem?)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:25:31PM -0500, Cliff Woolley wrote:
>
> > -----Original Message-----
> > Okay, I'm not 100% sure on this, but I think I spotted a problem in the
> > chunk filter such that two immortal buckets are getting inserted AFTER the
> > EOS bucket by means of transposed parameters to the
> > APR_BUCKET_INSERT_BEFORE macro.
>
> Okay, I had it the wrong way around, thankfully. It's the documentation
> that's got it wrong, not the chunk filter. So nix the chunk filter patch,
> as it's incorrect. Instead, we just need to change the docco in
> apr_buckets.h in APR-UTIL to reflect reality:
Didn't you say that mod_include used them the other direction? Does this
mean that mod_include is now wrong?
> It'd be really nice if the ring macros were documented, as that would have
> cleared up this confusion pretty quickly (as it was, I had to trace through
> the ring macros on a whiteboard to make absolutely sure of which way around
> they were supposed to go). I don't suppose anyone would object if I
> documented them? =-)
Heh... no :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: docco problem
Posted by Cliff Woolley <cl...@yahoo.com>.
> /**
> * Insert a list of buckets before a specified bucket
> - * @param a The buckets to insert
> - * @param b The bucket to insert before
> + * @param a The bucket to insert before
> + * @param b The buckets to be inserted
> * @deffunc void APR_BUCKET_INSERT_BEFORE(apr_bucket *a, apr_bucket *b)
> */
> #define APR_BUCKET_INSERT_BEFORE(a, b)
> [snip]
PS: This conflicts with my earlier patch to the insertion macros, obviously.
And I think my mailer munged some long lines, meaning it wouldn't apply
cleanly anyway. So if somebody's going to commit this, it's easiest to
apply the earlier patch first and then make this change by hand.
Thanks,
Cliff