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

["Mahad Ibrahim" <mahad.ibrahim.dev@gmail.com>]

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