On Thu, Jun 23, 2011 at 2:53 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Wednesday, June 22, 2011 17:04:49 Simon Glass wrote: >> +/* >> + * An assertion is run-time check done in debug mode only. If DEBUG is not >> + * defined then it is skipped. It does not BUG or halt U-Boot, but tries >> to + * continue execution in any case. It is hoped that all failing >> assertions + * are found before release, and after release it is hoped >> that they don't + * matter. But in any case these failing assertions >> cannot be fixed with a + * BUG-type reset (which may just do the same >> assertion again). >> + */ >> +#define assert(x) \ >> + ({ if (!(x)) printf("Assertion failure '%s' %s line %d\n", \ >> + #x, __FILE__, __LINE__); }) >> #else >> #define debug(fmt,args...) >> #define debugX(level,fmt,args...) >> +#define assert(x) >> #endif /* DEBUG */ > > the trouble with ifdef magic like this is that errors/warnings can be > introduced when DEBUG isnt defined, and then only noticed when DEBUG is > defined. so how about:
Symbian OS, that had an array of defensive programming features, had two ASSERT macros: Something like ASSERT_DEBUG(x) and ASSERT_ALWAYS(x). ASSERT_DEBUG(x) could be used more liberally because it is compiled out in production image and ASSERT_ALWAYS(x) could be used in more critical run-time errors. My rule of thumb for using these two was this: 1. ASSERT_DEBUG(x) was used for invariant checking, that's for catching errors that could arise out of programming errors. This was used more liberally in the code. 2. ASSERT_ALWAYS(x) was used to catch erros due to invalid run-time parameters that one may not be able to catch during testing. best regards, Aneesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot