On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote: [snip] > > > Note that MISRA is not universally lauded. As I understand, some of > > > its practices are contrary to other widely adopted coding policies. > > > > Sure. Some points are a laugh like "a null pointer should not be > > dereferenced". > > That one touches on interesting system philosophy though. Should > one guard _every_ pointer access with an "if (ptr == NULL)" check?
Only if the NULL can be a result of normal run-time operation. Memory allocation failures should be expected in normal run-time operations; even though they are undesirable, the program must always handle them. In library APIs where it's impossible to determine such pre-conditions, they must be checked... or we have a buggy library. > I'm personally used to the answer to that being "no", and being > able to rely on inputs being non-NULL ... unless they're explicitly > stated as allowing NULL. If the NULL can derive _only_ from programming error, then the assert() macro should be used instead. These can be optimized out with a configure option (along with blocks of code in #ifndef NDEBUG blocks), so these can provide reports for programmers without impacting runtime performance in deployment. > > Nonetheless, the code is IMHO at least better maintainable and more clear. > > I'm not sure what you mean to imply by that NULL example, but the > two philosophies I'm aware of are: > > - Having largely superfluous NULL checks obfuscates the code and > makes it less clear. If anyone wrongly passes a NULL, we get a > nice fast-fail that's easily tracked down and fixed. Plus, there > is a *LOT* of code (and runtime cycles) wasted on such checks. This model falls down in embedded devices and under heavy load with dynamic memory allocation. In neither case will it be remotely easy for the user of the device or application to produce a viable crash report. If this philosophy has a religious following, it comes with ceremonies that have the same effect on its practitioners as does Russian Roulette. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
