> server/config.c:396 > return !!(cmd->limited & (AP_METHOD_BIT << methnum)); > ^^ > > Is that a typo or intentional?
It's intentional. This line always sparks a VERY large debate. The reason for it is that it is the only way to ensure that you have a 1 or 0 result. By negating twice, the first negation always takes the result to 0 or 1, and second always gives the opposite result. > server/core.c:661 > AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use > this! */ > > If we shouldn't use it, why is it still here? Because people are lazy and most people didn't realize that comment existed. If nobody is using that function, remove it. > server/core.c:691 > /* Should probably just get rid of this... the only code that cares is > * part of the core anyway (and in fact, it isn't publicised to other > * modules). > */ > > Read the comment. Check to make sure nobody uses it, and remove it if nobody does. > server/listen.c:320 > /*free(lr);*/ > > Can this go? Was there a future purpose to this call, > or was it just old code commented out? It most likely highlights a memory leak more than anything else. These structures use to be malloc'ed, and free'd at the correct times. Now we use palloc to allocate them. I would bet that the free was left so that somebody would remember to look for the leak. Ryan
