httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Date Thu, 11 Oct 2001 07:21:32 GMT
On Wed, Oct 10, 2001 at 11:43:38PM -0700, Greg Stein wrote:
> On Wed, Oct 10, 2001 at 10:14:04PM -0700, Aaron Bannert wrote:
> > On Thu, Oct 11, 2001 at 04:40:14AM -0000, rbb@apache.org wrote:
> >...
> > >        do {
> > >   +        apr_off_t len_read;
> > 
> > You don't want to do that, you are growing and shrinking the stack for
> > each iteration through the loop.
> 
> Eh?
> 
> The compilers that I've written use the max size for the stack frame, set up
> the base register on function entry, and just index from there. There is no
> "grow / shrink" involved.

I believe you are mistaken. It is an optimization of a compiler to try to
preallocate the stack if it can determine the max stack size, but it can
not always be determined until runtime:

int main(int argc, char *argv[])
{
    int i;

    for (i = 0; i < argc; i++) {
        int j[argc];
        j[i] = i;
    }
    return 0;
}

I'd rather not wait to find out if my compiler is smart. And if you think
modern compilers are smart, one of the assembly lines produced from the
above code was:
    movl    %eax, %eax

That's obviously unnecessary, but that's what you get with automatically
generated code.

> Let's assume that I had no idea what I was doing, and "proper" compilers
> *do* grow/shrink the stack frame.... So fucking what?
> 
>    func(a, b, c)
> 
> "Oh no! That grows the stack frame!"
> 
> Feh.

You're right, we're already growing the frame once when we enter the
function, so why wait until later to do it again, over and over?

> I see absolutely no reason to complain about growing/shrinking the stack
> frame in a patch. Talk about other issues, but *leave* that one out.

I don't like making assumptions about my compiler, and I don't see why
you would want to discourage me from attempting to avoid these kinds of
mistakes in our code.

-aaron

Mime
View raw message