've written many production systems this way. i never once had a malloc failure that was not a result of a catastrophic bug or h/w failure.
except in the case where you know you might be requesting an unreasonable amount of memory, i have always thought that it makes more sense to limit the number of failure states by just quitting when malloc fails. i want my programs to be as deterministic as possible. i would much rather have them die than get into some untested failure state. (does any project that tries to recover from malloc failure actually test failure at each recovery point?) the current fad is c++ exceptions. the idea seems okay, but the programs i know that make use of c++ this way (mozilla comes to mind) do not seem to be very stable or reliable. - erik On Fri Jun 9 17:53:03 CDT 2006, [EMAIL PROTECTED] wrote: > Another example is using emalloc in libraries. I agree that it is > much simpler to just give up when there is not enough memory (which > is also not very likely case), but is that how the code is supposed > to be written if you are not doing research? > > Thanks, > Lucho
