[alsa-devel] [PATCH] ALSA: have snd_BUG_ON() always refer to arguments

[Mike Frysinger]

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