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

On Fri, 07 Aug 2026 17:41:36 +0200,
Mahad Ibrahim wrote:
> 
> On Fri Aug 7, 2026 at 5:15 PM PKT, Takashi Iwai wrote:
> > 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.
> 
> Thank you for the quick response and feedback.
> 
> You are right that strlen() + strscpy() is tedious and annoying to read.
> 
> sound/ already has helpers that do this, but each is local to one file
> with its own signature:
> 
>   safe_append_string()  sound/core/ump.c
>   append_ctl_name()     sound/usb/mixer.c
>   hda_append_suffix()   sound/hda/common/hda_local.h
> 
> Each of these functions practice the same string append technique
> however to slightly different effect. safe_append_string uses
> safe_copy_string() whose function body is above it in the same file.
> safe_copy_string() performs analogous to strscpy() however adds a
> filter which drops non-printable ASCII characters during the copy phase.
> 
> append_ctl_name() is simply an strlcat wrapper which when transitioned
> would result in the same strlen() + strscpy(). Only separating feature
> is that it returns the length of characters that would have been
> written (not necessarily the actual amount). However none of the callers
> use its return functionality.
> 
> hda_append_suffix() is a verbatim copy of strlen() + strscpy().
> 
> A solution I would propose is that all these functions which do the same
> thing, aside from safe_append_string, could be moved where they are
> accessible globally across sound/. This would remove the redundant need
> to use strlen() + strscpy() in replacement for strlcat() and would unify
> the sub-system under a single string append API.
> 
> safe_append_string is only called once in the entire sub-system, and could
> be replaced either within the function with the unified string
> append function, and a separate filterer replacing the safe_copy_string
> function or removed all together and managed inline within the single
> caller. However this function would require a more involved removal as the
> internal safe_copy_string is called twice; it is called once in
> safe_append_string(), and in sound/core/ump.c for a wrapper function
> ump_set_rawmidi_name().
> 
> An argument against this suggestion is that it would confine a string
> append helper to a single sub-system, while the rest of the kernel uses
> something else.
> 
> Additionally patch 1/7 shouldn't have open-coded anything at all.
> safe_append_string() was already a few hundred lines above the site I
> touched, and I should have used it.
> 
> This was based on https://github.com/KSPP/linux/issues/370, which I
> should have linked in the cover letter.
> 
> Thank you for your time.
> 
> Best regards,
> Mahad Ibrahim

Well, that leads to a basic question: why do we have to drop strlcat()
if most of callers would just need the equivalent function.

If strlcat() were super-dangerous, it's understandable to drop.  But,
it's not, and issues discussed in the github are minor and something
that can be addressed in strlcat() implementation; that is, can't we
rather re-implement strlcat() in a safer way, instead of killing it?

Sure, there are code calling strlcat() that could be optimized better.
They can be cleaned up.  But it alone can't be a reason that strlcat()
must die without mercy.


thanks,

Takashi