Carsten Breuer wrote: >> Perhaps we should use something like: >> >> void *allocate_or_exit(size); > > I would also make some defines in types.h: > > #define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC > #define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC > > With this, developers can't use malloc > accidentally.
This is just wrong. No one wants to malloc() to _always_ terminate the process. As I said, you have to differentiate the cases. If you alloc some big chunk of memory (like reading a .bin file for flashing, etc.), malloc() _may_ return NULL, and that case _must_ be checked. But in the vast majority of cases, malloc() is used to allocate small, fixed size structures. If a tiny malloc(64) fails, you would have to provide an error handling path that is guaranteed to not need additional memory. How would you make that guarantee? Do you know for sure, that your fprintf(stderr, "HELP!"); won't call malloc() itself? You can't. That's why it's better to leave those tiny mallocs unchecked. The only reason that those small mallocs would fail is a memory leak. Checking for NULL doesn't help there either - in the best case you will get a OOM after a random malloc, but won't get a hint on the _cause_ of the leak. There are much better tools for this job (just google around, there's everything from simple wrappers to valgrind -- no need to reinvent the wheel!). _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
