Re: [PATCH 0/7] ALSA: remove remaining strlcat() users under sound/

David Laight <[email protected]>
Newsgroups org.kernel.vger.linux-sound,org.kernel.vger.linux-kernel
Message-ID <20260807140454.1014cf33@pumpkin>
On Fri, 07 Aug 2026 14:15:27 +0200
Takashi Iwai <[email protected]> wrote:

> On Fri, 07 Aug 2026 13:41:32 +0200,
> Mahad Ibrahim wrote:
> > 
> > strlcat() is deprecated and slated for removal once its remaining
> > users are converted.  This series converts the sound/ users outside
> > of ASoC.
> > 
> > Each site is converted to an explicit offset plus a bounded copy:
> > strscpy() where the appended text has no format specifiers, and
> > scnprintf() where it does or where the resulting length is needed.
> > 
> > After this series the only remaining strlcat() user under sound/ is
> > sound/soc/codecs/wm_adsp_fw_find_test.c, which goes via ASoC.
> > 
> > Build-tested with allmodconfig and boot-tested on x86_64.
> > 
> > The generated strings were checked against the pre-patch code in a
> > userspace harness for empty, whitespace-padded, exact-fit and
> > oversized inputs, and came out identical.  No audio hardware was
> > available here, so the drivers themselves have not been exercised at
> > runtime.
> > 
> > Mahad Ibrahim (7):
> >   ALSA: ump: replace strlcat() with strscpy()
> >   ALSA: ac97: replace strlcat() with scnprintf()
> >   ALSA: cmipci: replace strlcat() with strscpy()
> >   ALSA: caiaq: replace strlcat() with strscpy()
> >   ALSA: usb-audio: replace strlcat() with append_ctl_name()
> >   ALSA: hiface: replace strlcat() with scnprintf()
> >   ALSA: usb-audio: replace strlcat() in longname construction  
> 
> Honestly speaking, I'm against those conversions.
> Why do we have to open-code at each place with strlen()+strscpy()?
> It's just harder to read than strlcat(), even more error-prone.
> 
> If an alternative is something like this, we really should reconsider.

Agreed.
Changing the code to not need strcat() is one thing, repeatedly
implementing a different version is silly.
Even using seq_buf isn't always ideal.

	David

> 
> 
> thanks,
> 
> Takashi
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.