__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