reentrant functions

Bernd Schmidt bernds_cb1 at t-online.de
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?

Because
  - 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.


Bernd
-- 
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