Hi Igor, > There is an emerging opinion that checking for malloc failures in > application code is counterproductive:
OK, that is not my point of view ;-). Writing to a zero pointer is allways "wrong code", even if we think that someone somewhere would clean up the mess we have created. > it is rarely tested > properly, thus almost never works as expected when allocation does > fail Well, you can use Test-Tools like Tessy to get a 100% coverage. I disagree here. > 2) it bloats the code, in some case substantially, and obscures > the "real" code flow The real code flow ends in nothing. There are embedded CPU's that have no problem with writing to zero. They just do it. So this is really nice to search errors. Good luck. > 3) it's very hard to write a proper rollback > algorithm for all situations No. If it is, the code is not well structured. > if the system is at the stage where > malloc fails, there's little guarantee that your recovery code will > work properly You know the difference betwenn stack and heap ;-). > many systems just kill the process when the memory > is exhausted instead of returning NULL What System? This is at least one argument. If all system would do, than perhaps you can leave this out. But then you are not able to clean things like a half written file or something like that. Best regards, Carsten _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
