httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [SUBMIT] mod_gzip 2.0.26a ( Non-debug version )
Date Mon, 17 Sep 2001 00:47:04 GMT

In a message dated 01-09-16 15:38:37 EDT, Cliff wrote...

> I should have been more explicit.  It's not bogus to do a conditional like
>  the one you just displayed.  I thought it was excessive to make it a whole
>  separate function that's only used in one place.  I thought it was bogus
>  to set it to the string "NULL" instead of the empty string, though
>  coincidentally a string that says "NULL" works out fine in the one place
>  where this function is used.  Then there the fact that I can't think of a
>  way that r->uri would ever be NULL.  Can it really?  Even when there is no
>  r->uri, we set it to the empty string.  That was that whole INTERNALLY
>  GENERATED bogosity that we scratched our heads over for a while and then
>  Ryan fixed it by setting it to "".  Under what circumstances will
>  r->uri==NULL?

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.

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.

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.


View raw message