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