rep.dot.nop at gmail.com
Sun Jun 8 19:15:51 UTC 2008
On Sun, Jun 08, 2008 at 05:35:22PM +0200, Denys Vlasenko wrote:
>On Sunday 08 June 2008 16:21, Bernd Schmidt wrote:
>> Denys Vlasenko wrote:
>> > Ok, this is a scenario: the user runs a "passwd" utility on NOMMU box.
>> > This utility has 20k of text and 80k of data. 70k of this data
>> > is occupied by des.c static buffer.
>> > At this moment the machine has only 90k RAM available, has no swap etc.
>> > It cannot satisfy load request for this application.
>> > So user gets some error message from the shell to this effect.
>> > If des.c buffer is not static but is __uc_malloc'ed, program will
>> > load succesfully, and then __uc_malloc will fail and exit
>> > with "no memory!" message.
>> > In both cases user's experience is essentially the same - [s]he cannot
>> > run the program because there is not enough memory.
>> Except the program that called crypt may have left some state -
>> temporary files, partial modifications in other files, whatever -
>> because it did not expect to fail at this point.
>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.
The problem is that this is not the expected behaviour and is absolutely
not standard confirming (in contrast, it breaks established standards
and expectations silently).
We can't do that.
>> Essentially your argument comes down to "it doesn't really matter what
>> the documented interface is".
>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:
Nobody cares (or should care) about impl details of a lib since the lib
is supposed to serve *exactly* the thing/standard it implements.
>2. Most of the programs do not handle OOM situation correctly anyway:
> - take any sufficiently big program and you will easily find
> a malloc call or new operator in C++ which is not checked for NULL.
That is no excuse.
> - some people are more honest about it and they implement
> and document this behavior, rather than just being lazy
> and allowing their programs to segfault when malloc fails.
> For example, gtk/Gnome libraries do this. They have allocators
> which just exit on allocation error. Well, busybox uses xmalloc
> extensively. etc...
>Which prompted me to think about more realistic approach
>to this problem. Yes, from the POV of malloc (libc) author,
>"lets return NULL on failure and let user deal with it".
>But for the user, it's not good enough. In many cases,
>user calls malloc deep inside the callchain, and it just
>HAS NO SANE WAY TO REACT TO OOM at that place!
That's not the point. Call it something_which_acts_a_bit_like_foo()
but if you disobey the expectations anybody puts on foo() it's just
not foo() anymore.
I think that there are not alot of users who want to use a
something_which_acts_a_bit_like_##whatever() api, even if it could be
ok for certain, very specific use-cases.
More information about the uClibc