From: David Wagner <daw@EECS.Berkeley.EDU>
Message-Id: <200010092105.QAA16245@mozart.cs.berkeley.edu>
Subject: Re: ick, ick -- grossness in linux kernel
Date: Mon, 9 Oct 2000 16:05:24 -0500 (CDT)
Because it's coming from a macro. A common idiom for C macros is
#define f(x) do { ... } while(0)
You do it this way so that you can write code like
if (...) then f(); else bar();
without getting undesired semantics. (Otherwise you'd need to
surround f() with curly braces in some places, e.g., as above.)
Your specific case looks like a use of the spin_lock_irqsave() macro,
as defined in include/asm/spinlock.h.
Of course, the frontend only sees the result after cpp inlines all the
macros. Consequently, you don't get to see the call to spin_lock_irqsave();
you just see what that macro expands to.
I've run into this type of problem before, and I've found that it
seems to be useful (at least in some cases) to modify the operation
of cpp to not expand certain macros. This way, the frontend can see
them. e.g., to model the semantics of spin_lock_irqsave(), it is
probably easiest to simply disable macro-expansion of it, and then
look for function calls to spin_lock_irqsave() in the AST.
I've run another example of this: gcc expands strcpy() to something
gunky, to support inlining in the case of static arguments (I think).
I have no idea how many other cases like this there may be lurking out
there, waiting to be discovered...
-- David
This archive was generated by hypermail 2b30 : 11/04/02 PST