bernds_cb1 at t-online.de
Tue Feb 12 15:18:33 UTC 2008
Denys Vlasenko wrote:
>> Before I apply this, I wanted to start a discussion about whether
>> __uc_malloc is a good idea at all. Space savings are all well and good,
>> but these come at a cost in reliability.
> There is no cost in reliability.
> Face it: if you have no free memory - you have no free memory.
> Just allocating a big static object (like des.c was doing)
> cannot magically guarantee that you will have this memory.
> It just shifts failure to some other place - program might fail to load,
> or hit malloc failure earlier in other plase, because des.c ate 70k.
IMO it's much better to have it fail with out of memory in places where
such behaviour is expected and documented as a possibility.
>> A number of libc functions can
>> now call exit, even though this is not documented and not expected by
>> any programs that call them.
> This is not exactly true. They can exit *if* program author did not
> install alternative handler for __uc_malloc failure.
And __uc_malloc is documented in which standard? Which manpage tells
program authors about the function calls that may need a handler installed?
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