[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5heecql74j.wl-tiwai@suse.de>
Date: Fri, 25 Jun 2021 09:45:48 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Nathan Chancellor <nathan@...nel.org>
Cc: "Geoffrey D. Bennett" <g@...vu>, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
clang-built-linux@...glegroups.com
Subject: Re: [PATCH] ALSA: usb-audio: scarlett2: Fix for loop increment in scarlett2_usb_get_config
On Thu, 24 Jun 2021 23:20:48 +0200,
Nathan Chancellor wrote:
>
> Clang warns:
>
> sound/usb/mixer_scarlett_gen2.c:1189:32: warning: expression result
> unused [-Wunused-value]
> for (i = 0; i < count; i++, (u16 *)buf++)
> ^ ~~~~~
> 1 warning generated.
>
> It appears the intention was to cast the void pointer to a u16 pointer
> so that the data could be iterated through like an array of u16 values.
> However, the cast happens after the increment because a cast is an
> rvalue, whereas the post-increment operator only works on lvalues, so
> the loop does not iterate as expected.
>
> Replace the post-increment shorthand with the full expression so the
> cast can be added in the right place and the look works as expected.
>
> Fixes: ac34df733d2d ("ALSA: usb-audio: scarlett2: Update get_config to do endian conversion")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1408
> Signed-off-by: Nathan Chancellor <nathan@...nel.org>
> ---
> sound/usb/mixer_scarlett_gen2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/usb/mixer_scarlett_gen2.c b/sound/usb/mixer_scarlett_gen2.c
> index fcba682cd422..c20c7f1ddc50 100644
> --- a/sound/usb/mixer_scarlett_gen2.c
> +++ b/sound/usb/mixer_scarlett_gen2.c
> @@ -1186,7 +1186,7 @@ static int scarlett2_usb_get_config(
> if (err < 0)
> return err;
> if (size == 2)
> - for (i = 0; i < count; i++, (u16 *)buf++)
> + for (i = 0; i < count; i++, buf = (u16 *)buf + 1)
> *(u16 *)buf = le16_to_cpu(*(__le16 *)buf);
That's still too error-prone.
Could you rather introduce another variable of u16 * type, and use it
instead? Ditto for u8 access for the code after that, too.
thanks,
Takashi
Powered by blists - more mailing lists