Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Mon, 1 Jan 2001 18:36:52 -0800 (PST)
From: rbb@covalent.net
To: Greg Stein <gstein@lyra.org>
cc: dev@apr.apache.org
Subject: Re: cvs commit: apr/include apr_general.h
In-Reply-To: <20010101182906.G10567@lyra.org>
Message-ID: <Pine.LNX.4.21.0101011830140.18436-100000@koj>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> > > Euh... this is dangerous as hell. Why do we need this?
> > 
> > A) why is this dangerous at all?
> 
> Casting a pointer to something else, and then presuming that a pool is at
> the beginning of the structure, is just plain dangerous. The whole point of
> being incomplete is to hide their organization; that assumption shouldn't be
> made.

Every single APR incomplete type has a pool as the first field.  That is
part of the design, and it is documented in the APRDesign doc.  This was
purposefully done so that something like this macro could be implemented.

> > The only difference is that we are getting it from
> > an incomplete type.
> 
> And that is the whole problem. It is incomplete -- the caller can't possibly
> know the pool is at the start of the structure.

Yes they can.  If it's an APR type, and it is incomplete, then it has a
pool as it's first field.  That is a part of the APR design, so if this
isn't true, then that type is broken.

> > b) we need this so that we don't leak memory like a sieve.  I committed a
> > use of this to the buckets code a few minutes ago.
> 
> Then write apr_file_get_pool(). Not a cast and an assumption.

That also means that we have to write apr_socket_get_pool and
apr_lock_get_pool and apr_mmap_get_pool, etc.  We control the type
definitions, and we control the macro.  This is very similar to what Dean
did with the ap_iol code.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------