You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Paul J. Reder" <re...@remulak.net> on 2001/08/25 01:02:35 UTC
Re: Ryan's comments about split_and_pass_pretag_buckets.
Ryan,
I am in the process of digging myself out of a weeks worth of lost mail,
but I am working to address the issues with my commited patch to mod_cgi,
mod_cgid, and mod_include.
Unless you have another preference, I will be moving the code to a common
location in util_filter.c. The only complication with that is that the
function currently passes the ssi context which would require that
mod_include.h be included in util_filter. This causes a cascade effect,
so I will probably be changing the parms so they don't reference the
context. Any complaints about this? Any alternative suggestions?
Thanks,
Paul J. Reder
Re: Ryan's comments about split_and_pass_pretag_buckets.
Posted by "Paul J. Reder" <re...@remulak.net>.
Ryan Bloom wrote:
> The big problem, is that this shouldn't be a function, it should be a macro.
This function/macro is called from mod_include, mod_cgi, and mod_cgid. There
are six calls in all. One of which is from the first level include processing
(send_parsed_content) and five are from second level include handlers.
I was taught that you should *consider* converting a macro to a function if
is is called more than 5 times. I initially chose to leave this a macro
because 6 calls was borderline and because the code was very simple.
When Ryan added the return to the macro I rethought that decision. I abhor
having returns hidden in macros, for the very reason illustrated here. The
macro now did the wrong thing in five of the six calls.
I will be turning this back into a macro, but removing the return. I will
pass in, set, and return a return value. The rest of the code that I added
(to check the return code after each call and after the return from the
include handlers) will remain.
The code will be commited shortly.
Paul J. Reder
Re: Ryan's comments about split_and_pass_pretag_buckets.
Posted by Ryan Bloom <rb...@covalent.net>.
The big problem, is that this shouldn't be a function, it should be a macro.
Ryan
On Friday 24 August 2001 18:59, William A. Rowe, Jr. wrote:
> ----- Original Message -----
> From: "Paul J. Reder" <re...@remulak.net>
> To: <de...@httpd.apache.org>
> Sent: Friday, August 24, 2001 6:02 PM
> Subject: Re: Ryan's comments about split_and_pass_pretag_buckets.
>
> > Ryan,
> >
> > I am in the process of digging myself out of a weeks worth of lost mail,
> > but I am working to address the issues with my commited patch to mod_cgi,
> > mod_cgid, and mod_include.
> >
> > Unless you have another preference, I will be moving the code to a common
> > location in util_filter.c.
>
> Huh? util_script exists soley to support the modules you just mentioned.
>
> Unless, as rbb points out, that the facilities will never be used outside
> of mod_include
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Ryan's comments about split_and_pass_pretag_buckets.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
----- Original Message -----
From: "Paul J. Reder" <re...@remulak.net>
To: <de...@httpd.apache.org>
Sent: Friday, August 24, 2001 6:02 PM
Subject: Re: Ryan's comments about split_and_pass_pretag_buckets.
> Ryan,
>
> I am in the process of digging myself out of a weeks worth of lost mail,
> but I am working to address the issues with my commited patch to mod_cgi,
> mod_cgid, and mod_include.
>
> Unless you have another preference, I will be moving the code to a common
> location in util_filter.c.
Huh? util_script exists soley to support the modules you just mentioned.
Unless, as rbb points out, that the facilities will never be used outside
of mod_include
Re: Ryan's comments about split_and_pass_pretag_buckets.
Posted by Ryan Bloom <rb...@covalent.net>.
No, this is wrong. This is a function that belongs in mod_include, so that it is
only in the server if mod_include is in the server.
Just turn it back into a macro. Right now, you have a function returning
a value, and you use that value to determine what to do. Pass in a result
parameter to the macro, and you can do the exact same thing.
Ryan
On Friday 24 August 2001 16:02, Paul J. Reder wrote:
> Ryan,
>
> I am in the process of digging myself out of a weeks worth of lost mail,
> but I am working to address the issues with my commited patch to mod_cgi,
> mod_cgid, and mod_include.
>
> Unless you have another preference, I will be moving the code to a common
> location in util_filter.c. The only complication with that is that the
> function currently passes the ssi context which would require that
> mod_include.h be included in util_filter. This causes a cascade effect,
> so I will probably be changing the parms so they don't reference the
> context. Any complaints about this? Any alternative suggestions?
>
> Thanks,
>
> Paul J. Reder
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------