On Thursday 17 December 2009, Carsten Breuer wrote: > > As I understand it, ANSI C says it returns NULL when it can't > > allocate memory. Anything else would be phenominally rude. > > You don't follow the thread, right? > You don't read the people who said it is a bad idea > to check the result ;-)?
I may have overlooked such blatantly bad advice. My point was that since NULL is a standard return value from malloc(), it needs to be checked. It's not a case of how a routine should behave given an out-of-spec input value ... it's a case of a very clearly defined function output. > Alex and some others came up with the point, that on linux > malloc doesn't come back anymore and send instead a sigterm. > He posted this link: > > http://article.gmane.org/gmane.comp.audio.jackit/19998 I referenced that in my message. You weren't representing that discussion accurately ... it's about overcommitting virtual memory, which can in a sense retroactively make a pointer from malloc() point to memory that's not present. > I have just checked that out and this is NOT TRUE > on my linux machine with Fedora Core 11. That failure mode is: alloc some memory, get back pointer to address space, and then at some later point you try writing to that memory. But since the system was using lazy allocation, at that "later point" there may not be any swapspace to page that memory into ... so what you get is a kind of deferred error, if the system is under very high load. > > For the record, I've never heard of *ANY* runtime environment where a > > malloc()/calloc()/... failure aborts the program. > > Well.. yesterday people said that right here on the list. Sometimes people don't know what they're talking about. The OOM killer situation is not a malloc() failure. It's about virtual memory overcommit. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
