reentrant functions

Bernd Schmidt bernds_cb1 at
Sun Jun 8 18:34:41 UTC 2008

Denys Vlasenko wrote:

> If this program wants to not be killed by OOM, it needs to install
> the handler for this situation. It is not difficult at all.

But this ignores the fact that there's a large body of software out 
there _which wasn't written against uClibc and whose authors have never 
  heard of it_.  It's completely unrealistic to expect programs to 
install such a handler, since it does not exist in the standards that 
people actually write code against.
If all that ever ran on uClibc-based systems was busybox, maybe I'd 
agree with you.

> No, my argument is twofold:
> 1. Minority of people who are careful enough to handle OOM coditions
>    correctly will not be deterred by the need to have a tiny speck
>    of uclibc-specific glue:

See above.  Completely unrealistic expectation as to the level of 
control we have over users.

> 2. Most of the programs do not handle OOM situation correctly anyway:

"Other people screw up, so let's do the same".  It's bad enough to have 
applications misbehave, but do we want to build unreliability right into 
the foundation?

> Again, my point is: if the program dies on OOM because it
> is badly written and does not expect NULL from malloc,
> why we are avoiding malloc inside libc as a plague?

  - two wrongs do not make a right.
  - we're implementing a specification where malloc is documented as
    being allowed to return NULL, and certain functions are _not_
    documented as allowed to call exit, and where people therefore have
    the realistic expectatino that this is not going to happen.

This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

More information about the uClibc mailing list