Date: Thu, 22 Feb 2001 23:23:48 -0800 From: Farooq Mela <fmela0@sm.socccd.cc.ca.us> To: Peter Seebach <seebs@plethora.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <3A961004.723691C9@sm.socccd.cc.ca.us> References: <200102230627.f1N6Rk618467@guild.plethora.net>
index | next in thread | previous in thread | raw e-mail
Peter Seebach wrote:
> It is a mistake to believe that you "don't have to worry about running
> out of memory". You should always check, every time, and exit as gracefully
> as you can.
>
> -s
Of course I realize that allocating memory can fail. That is why I use
xmalloc and friends - so that I can avoid having to check for failure
each time I want to allocate memory. I don't believe you understand what
I am proposing. Consider the following inside libc:
void *(*libc_malloc)(size_t)=malloc;
void *(*libc_calloc)(size_t, size_t)=calloc;
void *(*libc_realloc)(void *, size_t)=realloc;
void
set_allocator(void *(*func)(size_t))
{
libc_malloc=func;
}
/* Same type of functions for calloc and realloc.. */
Now, consider some other function that is part of libc, such as
getaddrinfo. Say it does the following:
/* code ... */
foo=malloc(128);
if (foo==NULL) {
/* do clean-up.. */
errno=ENOMEM;
return(NULL);
}
This would be replaced by:
foo=(*libc_malloc)(128);
if (foo=NULL) {
/* do clean-up */
errno=ENOMEM;
return(NULL);
}
It will still have to check for the allocation failing. But if this were
to be done, an application which installs its own allocators will not
have to worry about anything inside libc running out of memory, and will
not have to handle that error condition. Furthermore, inside the
user-defined allocator (xmalloc etc), other types of cleanup can be
handled if the real malloc() returns NULL. (Atexit can only do so much.)
Hope this clears it up.
-Farooq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A961004.723691C9>