You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2001/10/08 18:22:24 UTC

[PATCH] convert an apr_pcalloc() to an apr_palloc()

In the least this should save us a function call or two per request...

-aaron



Index: server/protocol.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
retrieving revision 1.47
diff -u -r1.47 protocol.c
--- server/protocol.c	2001/09/29 08:48:59	1.47
+++ server/protocol.c	2001/10/04 20:13:55
@@ -852,8 +852,10 @@
 
     ctx = f->ctx;
     if (!ctx) { /* first time through */
-        f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx));
+        f->ctx = ctx = apr_palloc(r->pool, sizeof(struct content_length_ctx));
+        ctx->saved = NULL;
         ctx->compute_len = 1;   /* Assume we will compute the length */
+        ctx->curr_len = 0;
     }
 
     /* Humm, is this check the best it can be? 

Re: [PATCH] convert an apr_pcalloc() to an apr_palloc()

Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Oct 08, 2001 at 10:01:48AM -0700, Greg Stein wrote:
> -0
> 
> Changing from apr_pcalloc() to apr_palloc() is kind of like omitting braces
> from the block of an 'if' or 'while' statement. Some time down the road, it
> is going to kick your ass [when somebody adds another field to the struct,
> not realizing that it won't be zeroed upon alloc].

I agree that we should be aware of potential hazards like this, but we're
talking about obviously uninitialized variables vs. an extra potentially
heavy function call. [It's been awhile since I could read i386 assembly,
but to me it looks like it's on the order of a minimum of 22 instructions
on Solaris 8].

-aaron


> On Mon, Oct 08, 2001 at 09:22:24AM -0700, Aaron Bannert wrote:
> > 
> > In the least this should save us a function call or two per request...
> > 
> > -aaron
> > 
> > 
> > 
> > Index: server/protocol.c
> > ===================================================================
> > RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
> > retrieving revision 1.47
> > diff -u -r1.47 protocol.c
> > --- server/protocol.c	2001/09/29 08:48:59	1.47
> > +++ server/protocol.c	2001/10/04 20:13:55
> > @@ -852,8 +852,10 @@
> >  
> >      ctx = f->ctx;
> >      if (!ctx) { /* first time through */
> > -        f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx));
> > +        f->ctx = ctx = apr_palloc(r->pool, sizeof(struct content_length_ctx));
> > +        ctx->saved = NULL;
> >          ctx->compute_len = 1;   /* Assume we will compute the length */
> > +        ctx->curr_len = 0;
> >      }
> >  
> >      /* Humm, is this check the best it can be? 

Re: [PATCH] convert an apr_pcalloc() to an apr_palloc()

Posted by Greg Stein <gs...@lyra.org>.
-0

Changing from apr_pcalloc() to apr_palloc() is kind of like omitting braces
from the block of an 'if' or 'while' statement. Some time down the road, it
is going to kick your ass [when somebody adds another field to the struct,
not realizing that it won't be zeroed upon alloc].

Cheers,
-g

On Mon, Oct 08, 2001 at 09:22:24AM -0700, Aaron Bannert wrote:
> 
> In the least this should save us a function call or two per request...
> 
> -aaron
> 
> 
> 
> Index: server/protocol.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
> retrieving revision 1.47
> diff -u -r1.47 protocol.c
> --- server/protocol.c	2001/09/29 08:48:59	1.47
> +++ server/protocol.c	2001/10/04 20:13:55
> @@ -852,8 +852,10 @@
>  
>      ctx = f->ctx;
>      if (!ctx) { /* first time through */
> -        f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx));
> +        f->ctx = ctx = apr_palloc(r->pool, sizeof(struct content_length_ctx));
> +        ctx->saved = NULL;
>          ctx->compute_len = 1;   /* Assume we will compute the length */
> +        ctx->curr_len = 0;
>      }
>  
>      /* Humm, is this check the best it can be? 

-- 
Greg Stein, http://www.lyra.org/