> One of the common threads there is needing to have a handle on > just how common an error is before choosing strategies for > dealing with it.
I did a pass of OpenOCD in the early days where I fixed all the error paths for malloc() where malloc() was greater than a few bytes. I have no evidence that skipping checks for allocating a "few bytes" has caused problems in OpenOCD, but it can be an eye-sore. That made stability tolerable when working with huge binaries on an embedded host. There are *LOTS* of unchecked mallocs in OpenOCD and I think tools could enumerate them. I have no plans to go after these malloc()'s and introducing failure paths, but I wouldn't turn down a good patch to fix stuff like that. Of course resources tracking in C++ and exception handling comes to mind as a much more robust solution to such problems. I'm not arguing for using C++, I'm just saying that there is nothing automatic that just takes care of this for us now. W.r.t. exception handling in C++, I hate to mention that it relies on(or at least can be implemented such that it relies on) dynamic memory allocation for it's implementation of throwing an exception ;-) -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
