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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc