__uc_malloc hooks

Denys Vlasenko vda.linux at googlemail.com
Mon Sep 17 15:06:43 PDT 2007


On Monday 17 September 2007 18:34, Rob Landley wrote:
> > For libc, this is not acceptable. libc has (potentially) diverse set of
> > users, some of them absolutely must have robust out-of-memory reporting
> > (e.g. databases).
> 
> In which case libc passes the NULL back to userspace and it's userspace's 
> problem.  This is what libc implementations have always done, correct?
> 
> > Because of that it's inacceptable to do this in libc:
> >
> > 	char *tempbuf = malloc(sz);
> > 	if (!tempbuf)
> > 		abort();
> 
> I agree that is _not_ something libc should be doing.
> 
> > __uc_malloc() solves this problem.
> 
> Solves what problem?  Why is the 30 year old defined well-behavior a problem?

The problem of sometimes needing to call malloc deep inside
libc internals with no way to return error code.

static void
des_init(void)
{
...
        if (!__uc_des_C_ptr) {
                /* No need to zero it out, it is fully initialized below */
                __uc_des_C_ptr = __uc_malloc(sizeof(C));
        }
...
}

void
encrypt(char *block, int flag)
{
        des_init();


See? encrypt() is returning void -> it can't return NULL if internal malloc failed!
And void-ness of encrypt() is a part of libc API, we cannot redefine it.
--
vda


More information about the uClibc mailing list