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
--------------------------------------------------------------