Unless you have a unit test framework that can simulate no mem failure, I'm not sure its worth checking for it.
I've worked on toolkits intended for use in embedded controllers, we used coding patterns much like in https://github.com/txdv/libuv/commit/9fcb445b16472d60145593eb7c1f6b6a8abcbc7c and I never saw any of our code survive our unit testing framework, despite that we wrote it knowing it would be tested under memfail conditions. Its very, very hard to get right. basically, we ran our unit tests under a loop: for A = 0, ... do run test, causing A'th call to malloc() to return NULL if test ran less than A mallocs and passed we are done if not assert test failed with ENOMEM continue end You can do this by using LD tricks to replace malloc(), or malloc callbacks, or... lots of ways. Symbian used to have a mem-monkey that would randomly cause malloc to fail... that caused bugs to fall like rain :-(. Anyhow, the end of this is that error paths in general tend to be poorly tested, but eventually things like fd limits or file permissions will get hit, bugs reported, bugs fixed. Out of memory errors, though, rarely happen on modern OSes, not for small allocations, so bugs never get reported. I used to think the old xalloc() approach was a crux for lazy programmers, now I think its the only sane way to go *if you don't have mem fail unit tests*. That's my two bits, Cheers, Sam -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
