Re: [PATCH] ALSA: cmipci: Use strscpy() in snd_cmipci_create()

[Takashi Iwai]

On Fri, 23 Oct 2026 20:40:59 +0200,
David Laight wrote:
> 
> On Thu, 22 Oct 2026 18:40:11 +0200
> Thorsten Blum <blum@xxxxxxxxxx> wrote:
> 
> > To prepare for removing strlcat() from the kernel [1], use strscpy()
> > instead with the current driver name length as the append offset. Also
> > use size_t in the multi-channel branch to match strlen()'s return type.
> > 
> > No functional change.
> > 
> > Link: https://github.com/KSPP/linux/issues/370 [1]
> > Signed-off-by: Thorsten Blum <blum@xxxxxxxxxx>
> > ---
> >  sound/pci/cmipci.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/sound/pci/cmipci.c b/sound/pci/cmipci.c
> > index 9d9f784e3a8c..5722b722da95 100644
> > --- a/sound/pci/cmipci.c
> > +++ b/sound/pci/cmipci.c
> > @@ -2980,11 +2980,15 @@ static int snd_cmipci_create(struct snd_card *card, struct pci_dev *pci,
> >  		query_chip(cm);
> >  	/* added -MCx suffix for chip supporting multi-channels */
> >  	if (cm->can_multi_ch) {
> > -		int l = strlen(cm->card->driver);
> > +		size_t l = strlen(cm->card->driver);
> > +
> >  		scnprintf(cm->card->driver + l, sizeof(cm->card->driver) - l,
> >  			  "-MC%d", cm->max_channels);
> > -	} else if (cm->can_ac3_sw)
> > -		strlcat(cm->card->driver, "-SWIEC", sizeof(cm->card->driver));
> > +	} else if (cm->can_ac3_sw) {
> > +		size_t l = strlen(cm->card->driver);
> > +
> > +		strscpy(cm->card->driver + l, "-SWIEC", sizeof(cm->card->driver) - l);
> > +	}
> 
> There are all sorts of reasons for not using strlcat() and various ways
> of changing code so that it doesn't need to do the string concatenation.
> But replacing calls with strlen() and strscpy() is just plain stupid.
> 
> It has no benefits and lots of downsides.

Right.  The whole actions look to me like a crusade to a wrong goal.

I was too tired of discussing the same thing again and again, so I
gave and took it once; but now I change mind and drop it again from
the queue.  The other patches from Thomas were OK as they can be seen
as optimizations, but this one has only downsides.


thanks,

Takashi