On Fri, Nov 7, 2008 at 03:22, Takashi Iwai wrote:
At Fri, 7 Nov 2008 03:05:56 -0500, Mike Frysinger wrote:
On Fri, Nov 7, 2008 at 03:03, Takashi Iwai wrote:
At Fri, 7 Nov 2008 02:57:40 -0500, Mike Frysinger wrote:
On Fri, Nov 7, 2008 at 02:38, Takashi Iwai wrote:
At Fri, 7 Nov 2008 02:29:25 -0500, Mike Frysinger wrote:
it also breaks valid C code if there were side effects in the (cond) as any other macro which does not properly utilize every argument exactly once.
BTW, what do you mean this exactly?
any potent statement. such as assignment or pre/post increment/decrement or ...
Well, in that case, such a code itself is buggy :)
i'm not advocating doing this sort of thing, i'm saying that functions/macros should be written correctly so as to not break standard C behavior. a guy developing a codec driver could waste a lot of time because of this sort of thing.
Well, no, it's a clear bug of the driver.
A macro that ignores arguments is normal. Or do you think assert() isn't a part of "standard" C ? :)
we arent talking about assert() here nor are we talking about assert() behavior, but i would say it was a poor decision. the fact that it's called snd_BUG_ON() instead of snd_WARN_ON() is also a bit broken imo. BUG() kills the kernel while WARN() complains, and snd_BUG_ON() is clearly in the latter category.
that said, you could just define snd_BUG_ON() in terms of WARN_ON() all the time: #ifdef CONFIG_SND_DEBUG # define SND_DEBUG 1 #else # define SND_DEBUG 0 #endif #define snd_BUG() WARN(SND_DEBUG, "BUG?\n") #define snd_BUG_ON(cond) WARN(SND_DEBUG && (cond), "BUG? (%s)\n", __stringify(cond)) -mike