Re: [PATCH] ALSA: opti9xx: shut up gcc-10 range warning

[Takashi Iwai <tiwai@suse.de>]

On Thu, 30 Apr 2020 08:12:07 +0200,
Takashi Iwai wrote:
> 
> On Wed, 29 Apr 2020 21:02:03 +0200,
> Arnd Bergmann wrote:
> > 
> > gcc-10 points out a few instances of suspicious integer arithmetic
> > leading to value truncation:
> > 
> > sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure':
> > sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
> >   322 |   (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
> >       |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
> > sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask'
> >   351 |   snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
> >       |   ^~~~~~~~~~~~~~~~~~~~~~
> > sound/isa/opti9xx/miro.c: In function 'snd_miro_configure':
> > sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
> >   873 |   (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
> >       |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
> > sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask'
> >  1010 |   snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
> >       |   ^~~~~~~~~~~~~~~~~~~
> > 
> > These are all harmless here as only the low 8 bit are passed down
> > anyway. Change the macros to inline functions to make the code
> > more readable and also avoid the warning.
> > 
> > Strictly speaking those functions also need locking to make the
> > read/write pair atomic, but it seems unlikely that anyone would
> > still run into that issue.
> > 
> > Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Applied now, thanks.

BTW, the lack of locking is no problem in this code.
Those lines are called only at the initialization in the probe
function, so can't race.


thanks,

Takashi