snd_assert() removal

snd_assert() removal

[Rene Herman]

Hi Takashi.

Just see the snd_assert() removal. Much better as far as I'm concerned 
but just as a remark -- there's many combined ones of the form:

diff --git a/sound/isa/cs423x/cs4236_lib.c b/sound/isa/cs423x/cs4236_lib.c
index 33e9cf1..6a85fdc 100644
--- a/sound/isa/cs423x/cs4236_lib.c
+++ b/sound/isa/cs423x/cs4236_lib.c
@@ -967,7 +967,8 @@ int snd_cs4236_mixer(struct snd_wss *chip)
         int err;
         struct snd_kcontrol_new *kcontrol;

-       snd_assert(chip != NULL && chip->card != NULL, return -EINVAL);
+       if (snd_BUG_ON(!chip || !chip->card))
+               return -EINVAL;
         card = chip->card;
         strcpy(card->mixername, snd_wss_chip_id(chip));

in there. Just thought I'd point that Andrew Morton has been pushing 
back on multiple conditions per regular BUG_ON()/WARN_ON() lately as 
they end up giving less useful information then split ones ("so what 
triggered?").

Just a remark as said but if you agree with him, maybe now is the best 
time to split them directly as well.

Rene.

Re: snd_assert() removal

[Takashi Iwai]

At Wed, 13 Aug 2008 12:16:33 +0200,
Rene Herman wrote:
> 
> Hi Takashi.
> 
> Just see the snd_assert() removal. Much better as far as I'm concerned 
> but just as a remark -- there's many combined ones of the form:
> 
> diff --git a/sound/isa/cs423x/cs4236_lib.c b/sound/isa/cs423x/cs4236_lib.c
> index 33e9cf1..6a85fdc 100644
> --- a/sound/isa/cs423x/cs4236_lib.c
> +++ b/sound/isa/cs423x/cs4236_lib.c
> @@ -967,7 +967,8 @@ int snd_cs4236_mixer(struct snd_wss *chip)
>          int err;
>          struct snd_kcontrol_new *kcontrol;
> 
> -       snd_assert(chip != NULL && chip->card != NULL, return -EINVAL);
> +       if (snd_BUG_ON(!chip || !chip->card))
> +               return -EINVAL;
>          card = chip->card;
>          strcpy(card->mixername, snd_wss_chip_id(chip));
> 
> in there. Just thought I'd point that Andrew Morton has been pushing 
> back on multiple conditions per regular BUG_ON()/WARN_ON() lately as 
> they end up giving less useful information then split ones ("so what 
> triggered?").

That's true.

> Just a remark as said but if you agree with him, maybe now is the best 
> time to split them directly as well.

Well, I don't mind to apply more patches now ;)


Takashi