Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@samba-tng.org>
To: "APR Development List" <dev@apr.apache.org>
Cc: "David Reid" <dreid@jetnet.co.uk>,
	<elrond@samba-tng.org>
Subject: RE: Memory code...
Date: Wed, 9 May 2001 23:13:49 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOGEKODNAA.striker@samba-tng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <045701c0d8b1$f6155ca0$6400a8c0@godzilla>
Importance: Normal

> OK.  I've also made some more changes so that the _free and _destroy
> functions return an APR_STATUS code rather than a void.  A lot of
> compilers
> moan when you try to use a void and being able to check the
> return value is
> a good thing.  On that note we should probably have the individual systems
> also returning an apr_status_t from their free functions and passing the
> value back up to the main free and then back to the user, in case of an
> error...

Hmmm, well the reason for using void is that you _don't_ want to
check a return value. In case of destroy you wish it to be destroyed and
be done with it. Same goes for freeing of memory.

In case you really want this, you would indeed want to make the change
to let the individual memory system return a value.

> I'll be committing some changes real soon...

Ok.

> The test app is written and once CVS gets sorted out I'll commit it.
>
> Looking at the function names, can we drop the system and simply refer to
> all this as apr_memory_t and so on?

Fine by me. We already came up with xxx_mem_sys_xxx, xxx_sms_xxx,
xxx_ms_xxx, but xxx_memory_xxx should be ok too ;-)

Sander