Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Mon, 17 Sep 2001 01:05:47 -0400 (EDT)
From: Cliff Woolley <cliffwoolley@yahoo.com>
To: <dev@httpd.apache.org>
Subject: Re: [SUBMIT] mod_gzip 2.0.26a ( Non-debug version )
In-Reply-To: <97.1b4fab9d.28d6da48@aol.com>
Message-ID: <Pine.LNX.4.33.0109170101500.9302-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 17 Sep 2001 TOKILEY@aol.com wrote:

> That call to mod_gzip_npp() ( Null Pointer Protection ) that remains
> in the debug code was actually an oversight. I have never actually
> seen the 'r->uri' pointer cause a segfault inside any standard Apache
> module user-exit, hook, or filter callback.

It did up until about two weeks ago, but then that was because r->uri was
set to a completely bogus value (the string "INTERNALLY GENERATED
file-relative req" or something like that), rather than just "".  =-)  I
don't think r->uri can be actually NULL, though (somebody correct me if
I'm wrong).

> If you look at the 'debug' version of mod_gzip.c that was submitted,
> however, you will see that it was quite necessary to have NPP for
> debug mode since there are tons of places where debug is trying to
> print things that might very well be NULL.

Ahh....

> Solaris version started exploding all over the place in DEBUG
> mode just because pointers were NULL so that's when the
> Null Pointer Protection stuff went in.
>
> The reason it's a function is that it used to do a whole lot of
> other things if/when something showed up as NULL ) that
> weren't apppriate for a macro ( Used to write a complete separate log
> file for things that turned up NULL during request hooks and such ).
>
> In non-debug mode... it's really all pretty irrelevant.

Okay, that makes sense.  Thanks for the explanation.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA