Messages in this thread | | | Date | Thu, 24 Jun 1999 10:23:51 -0400 (EDT) | From | Jeff Garzik <> | Subject | Re: [PATCH] *(int*)0 = 0 & variations |
| |
On Thu, 24 Jun 1999, Riley Williams wrote: > >> +#else > >> +#define kassert(cond) (void) abs(cond) > >> +#define kassertoops(cond) (void) abs(cond) > >> +#endif > > > Any code depending on assert evaluating the condition is broken > > IMHO. > > IMHO also, but the general concensus appears to be in favour of it. > I've put an '#if 1'-#else-#endif block in the code, defaulting to > not evaluating, but changing the '#if 1' line to '#if 0' inverts that.
What consensus do you see here? Two people? I didn't even see any cases where this behavior was said to be used -- only said to be needed in a few rare cases.
AC posted in this thread, saying that assert code already exists in the kernel, in the networking code (grep for BUG_TRAP). Guess what? It evaluates to null. In fact, grepping around, every assert macro I could find in the kernel (not many, granted) evaluates to null in its non-debug form.
Evaluating to null is the standard set by both the existing kernel sources and ANSI C. NOT evaluating to null potentially slows down a fast path, if a kassert() is used there. Why use it, if it breaks with tradition and creates slower production code?
So, my suggested updates to your kassert.h:
o Evaluate to null in non-debug form ;-) Copy code from BUG_TRAP instead of simply "#define kassert(cond)". It wraps a null do-while.
o Allow developer to redefine REPORT_LEVEL by wrapping it in an #ifndef
o Is there some central file that the CONFIG_xxx selection can be moved to, so avoid changing each port's Config.in? Maybe source linux/kernel/Config.in (new file) from each port instead.
There are too much common stuff in the port Config.in's anyway, IMHO.
Regards,
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |