From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 318EB477293 for ; Fri, 7 Aug 2026 15:41:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786117312; cv=none; b=jC2X38W14fDb6fQ2uB6xqSAxxvjiMZKq6xsQ+3KObU/E5kYuXdDyBlegyT0wPwUvFZjXOkjPhUtm5vH0eqEv9cHIu6RuED7PHomhnj7r3zrZr4wSYZNRHyIcHxvvOQQW2Y9FawDhsaiBnhYPNJ1852hhueVZ2IO1vzD5d9tnd1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786117312; c=relaxed/simple; bh=x+I72SNOGyldQff5bNCHimqzCxMWtyiogesLGVpujEQ=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=RnJ04QCQEzjmNSAiZQEaQd4PYq3PCeCtcVtAz5flzBJYtLfvstBR8ON1df6j25jRXCiji6Y3T6sLsfqx5W+SmyJeKF+07JsgKVFqzAafIUGDD8EFrOu2DxHnFrgll/G6eikzhWJKCeqSGKu1Ojhe0W7k10iGI6iXQmPEzRMHb0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lV8L6KGe; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lV8L6KGe" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-384930ca5e2so3795943a91.3 for ; Fri, 07 Aug 2026 08:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786117310; x=1786722110; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Zw4tEI7v5Ozfyr0IaEycsWq3znAQRlLmo34+BVtZE/s=; b=lV8L6KGeicdgbnhn3TUoObu3Q8Rw0+zCiyo0HaHtfTqhCM4Yz+xSNLsArsxge/Pwar 0nnSRcSpdrNyIN1pCpBol39GUxkNbFr2G5DA1w/+xCO4MRan+OSa6Etak6QJRRlaedAv 4MfmASieA5S6OOufWrSUMtH72AEXaolahrXdf9A9gh5KBWzR+ZkonRAJzjK+eQPMP1aB bugnZnhTkKxZCcIVJXvimYrNmYMPYn4xGhUCbaGIZD0ccyHX/RPtXA82HEuey3jQxbAI YcP7AYqeSn88Y6jnALKT9AuKGne5h4aWCx3hAh0b7MfENy/b97JTFWp6BHFAf7CXhyh6 DdZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786117310; x=1786722110; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Zw4tEI7v5Ozfyr0IaEycsWq3znAQRlLmo34+BVtZE/s=; b=qdDsZQB8EFuldwwCQK2V0ajT6+DfdoFiaB6P5kUFqg4R36EOFUx1z3Gwdp1SA89n3T +1i1EAcPo3Uot0opVPX+fsrN6U0NVuRecNTJg1naHcZ36VGQROSyw8ShxMvkMyKuzsTF GgH6ut2wrImaYQkjIbS9AkrE55vNL10xZQ6NWVKLvvxuqsPwvVq3fAleBYORGQEh3lS+ aBRjAFmh7r2YO9g1C8bB1XU6lQDDsuhE0Crj9t+F1pMYBdc7K38KjbXlM1GJ4gslzIVq g2BzxmZGt5vwaRtGMDOIQlHvingYVGJcWwzqAYOt5BxrTpLHXb6wcfbb+CeBiGK7yZC4 ol3g== X-Forwarded-Encrypted: i=1; AHgh+RoAMH1dPBdeti7XmPqXnIq2KGEqK28GHxkC2XUdvFjOxQ9B8ZNtrmcfSeNW7JuXBJJESa+QwQeC3Fj5SdI=@vger.kernel.org X-Gm-Message-State: AOJu0YzoGpXqfMOqJ3Nx+wJjFGDNMWwfDNOCswvfRbnpUENFpBMFSmPA NDXFC9OFDR6ZaENyDWxMZYimMHTWKtL0fKRdD+5/5F0XLIOgDZf3j4/3 X-Gm-Gg: AR+sD12dEj7Oqt/b212a1XDI/+SxLZanjdPyZOTTw0PLSwS2CBMy1CDSGldZEVK2/uu KDEklCpXw9T1wB7/acMAXjYjG9f+NtwAAntJMlTLC/O0FAwBg21tohG5TWfdcPpZSQLchH1Zc+/ v628zN4DOpI8bO5cZgiK5U+y4mWd5obH0ZKtayCslGXYA4WPlNpa/MzKKaC6Y0QKGWB+DXtJMQt reEvZ02l/h5D1AhFlLdyzDyhycTHx0cy1c0L8Y1pUaOsuj+cvT5fit6B3b1rOE8t6CuFPwnHWZH TGqK+taQPaVayxydwR28VLQfLiiO85mMYEAaupPg1W7Z+mj1Fqs0tsCn6pC9SRbGMS1m5EPf3On 6eR01rSU91xNxuv3pWd6Vb8HH3yHyqSZQulSVMqriABd0W4O3vMNOu/KdMl22KQWzcgEmNG7s7y DUT7P15IUTwArtgc9lL4ug5gg0Vld/nKsUQ0wizWQJhJci2Ug9KaIpgB4NMwWS3j7dA2YN5Q== X-Received: by 2002:a17:90b:46:b0:38e:67e1:15b with SMTP id 98e67ed59e1d1-3903c5363a5mr26961879a91.6.1786117310240; Fri, 07 Aug 2026 08:41:50 -0700 (PDT) Received: from localhost ([2400:adc1:447:6d00:6351:4475:eeb9:18f1]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-315be86e917sm10212507eec.5.2026.08.07.08.41.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Aug 2026 08:41:49 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 07 Aug 2026 20:41:36 +0500 Message-Id: Cc: "Takashi Iwai" , "Jaroslav Kysela" , "Kees Cook" , "Andy Shevchenko" , , Subject: Re: [PATCH 0/7] ALSA: remove remaining strlcat() users under sound/ From: "Mahad Ibrahim" To: "Takashi Iwai" , "Mahad Ibrahim" X-Mailer: aerc 0.21.0 References: <20260807114139.1661-1-mahad.ibrahim.dev@gmail.com> <87jyq2azz4.wl-tiwai@suse.de> In-Reply-To: <87jyq2azz4.wl-tiwai@suse.de> 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