On Tue, May 02, 2000 at 05:10:40PM -0400, Noel L Yap wrote:
> Code that checks for NULL as an error condition is, IMHO, incorrect (unless, of
> course, the code never expects malloc to be called with a zero argument).
> Correct code would look like:
> p = malloc(n);
> if((p == NULL) ^ (n == 0))
> {
> /* error */
> }
>
> Also, allocating 1-byte chunks could potentially fragment memory and slow down
> the process.
Probably not. Most malloc()'s today will see that you only want
one byte and up the request to the closest power of two that
is word aligned with the machine that we are on.
>
> Currently, most (if not all) calls to free() check to see if the argument is
> NULL anyway (ie if(p != NULL) free(p)). The only thing that's gained by not
> wrapping free() is one less function call for each free(). If you're worried
> about that extra function call, the wrapper could be made a macro.
would this be a good thing(tm) for someone to go and do?
donald
>
> Noel
>
>
>
>
> [EMAIL PROTECTED] on 05/02/2000 04:50:40 PM
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: question (preference?) about xmalloc
>
>
>
>
> Noel L Yap writes:
> >
> > I was looking at that, too. I tend to feel that 0-byte allocations should be
> > allowed (returning NULL) and, if systems' frees don't handle NULL properly,
> > there should be an xfree() that'll do so.
>
> The problem with that is that code that calls malloc almost always
> assumes that a NULL return means there's no more memory available and
> thus errors out. Interpreting 0-byte requests as 1-byte requests
> ensures that you don't get a NULL return unless you really are out of
> memory and, as an extra added attraction, you don't have to wrap free.
>
> -Larry Jones
>
> It's not denial. I'm just very selective about the reality I accept.
> -- Calvin
>
>
>
>
>
> This communication is for informational purposes only. It is not intended as
> an offer or solicitation for the purchase or sale of any financial instrument
> or as an official confirmation of any transaction, unless specifically agreed
> otherwise. All market prices, data and other information are not warranted as
> to completeness or accuracy and is subject to change without notice. Any
> comments or statements made herein do not necessarily reflect those of
> J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.
>