Hi all,
> 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. If it is guarantied, that malloc exits under linux, we can also just use a define for that: #ifdef unix # define allocate_or_exit(x) malloc(x) #elif (defined WIN32) // Windows code here #endif Of course, we need something for the above define in types.h Just some thoughts Carsten Am 17.12.2009 00:53, schrieb Carsten Breuer: > Hi all, > > Well, this is really interesting. > > If we use this, i think it is necessary > to use even another name and avoid anything > that points to the name "malloc" to avoid > any future discussions about this topic. > > Perhaps we should use something like: > > void *allocate_or_exit(size); > > This would make it perfectly clear what happening > and i have no problem with that. It is fail safe. > > > Best Regards, > > > > Carsten > > Am 17.12.2009 00:34, schrieb Austin, Alex: >> Actually, probably not a bad idea for a long-term fix. AFAIK, Posix >> OSes will inform you of malloc failures with SIGKILL rather than NULL. >> The article on gmane.comp.audio.jackit had some very good discussion >> on this point, so emulating that functionality under Windows is probably >> a decent way to go. >> >> http://article.gmane.org/gmane.comp.audio.jackit/19998 >> >> On Wednesday 16 December 2009, David Brownell wrote: >>> >>> On Wednesday 16 December 2009, Igor Skochinsky wrote: >>>> Actually, I think a common emalloc() function that (in the unlikely >>>> event of malloc failure) prints an error message and exits the app is >>>> a better choice than sticking checks everywhere. >>> >>> Not a bad idea for a near-term fix... >>> >>> _______________________________________________ >>> Openocd-development mailing list >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >> _______________________________________________ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
