Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 11 Apr 2001 12:40:46 -0400 (EDT)
From: Cliff Woolley <cliffwoolley@yahoo.com>
To: Greg Marr <gregm@alum.wpi.edu>
cc: <dev@apr.apache.org>
Subject: Re: Buckets code question
In-Reply-To: <5.1.0.12.2.20010411115713.00a96ec0@mail.charter.net>
Message-ID: <Pine.GSO.4.32.0104111233080.5653-100000@cobra.cs.Virginia.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Apr 2001, Greg Marr wrote:

> I agree.  Having macros that look like functions, but have return
> statements in them, is bad.  It also prevents those macros from being
> made into inline functions without changing all the places that call
> them.

I'll consider that three +1's on concept... me, Greg Marr (yes?), and
FirstBill.  I'll touch this up and commit it this afternoon.  I'd also
like to remove the return NULL; lines in the macro.  There are two ways to
do that:

   1)  ap__b = NULL; continue;
   2)  get rid of the malloc failure checking entirely
   3)  ignore this issue and leave the return NULL's in there.

I prefer #1, but I predict being overruled by the group on this since many
of you think it's better to segfault than attempt to gracefully handle
malloc failures.  So assuming #2 is preferred by the group, does everyone
like the following as the new apr_bucket_do_create macro?

#define apr_bucket_do_create(ap__b,do_make)     \
    do {                                        \
        apr_bucket *b;                          \
        b = calloc(1, sizeof(*b));              \
        ap__b = do_make;                        \
        APR_RING_ELEM_INIT(ap__b, link);        \
    } while(0)


--Cliff


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