__uc_malloc hooks

[Rob Landley]

On Monday 17 September 2007 5:00:23 am Denys Vlasenko wrote:
> On Monday 17 September 2007 05:03, Rob Landley wrote:
> > On Saturday 15 September 2007 3:19:33 am Mike Frysinger wrote:
> > > more to the point ... how exactly would __uc_malloc be useful ?  i dont
> > > think ive ever seen malloc() return NULL as the kernel is the first to
> > > find out about the OOM situation and properly nukes any userspace app
> > > before it ever sees the relevant NULL ...
> > > -mike
> >
> > Generally malloc() returns NULL when you've exhausted virtual memory (not
> > physical memory, which you find out about after the fact by the OOM
> > killer shooting you in the head when you dirty enough pages).
>
> Or when you hit a rlimit. Don't forget about it, it's a valid scenario
> where users of libc have every right to expect correct behavior.

*shrug*  If an allocation returns NULL, then returning NULL is the correct 
behavior.  It's the calling application's job to care.

> > Not much of a concern
> > on 64 bit platforms, but on 32 bit you can trivially run into this if
> > you've done a couple of large mmap() calls...
> >
> > That said, testing for NULL is seldom useful because attempts to use the
> > result give you a nice null pointer dereference and a segfault, cleanly
> > ending the program anyway.
>
> 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?

> For 99% of users which don't care, 

The remaining 1%, like busybox, have already come up with their own wrapper.  
Why bloat uClibc?

> it works exactly as above piece pf code. For the remaining 1%
> who care and installed a callback, it returns a notification.

How do I disable this useless and nonstandard bloat at compile time?  And in 
the short term, how do I stop it from breaking the build?  (I guess I can 
drop a patch to revert the commit into my patches directory.)

> --
> vda

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.