From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) by sourceware.org (Postfix) with ESMTPS id 651AC3943408 for ; Mon, 5 Dec 2022 17:48:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 651AC3943408 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eyrie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eyrie.org Received: from lothlorien.eyrie.org (96-90-234-101-static.hfc.comcastbusiness.net [96.90.234.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 77C2D1185B3; Mon, 5 Dec 2022 09:48:41 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 3488AB42950; Mon, 5 Dec 2022 09:48:40 -0800 (PST) From: Russ Allbery To: Alejandro Colomar via Libc-alpha Cc: linux-man@vger.kernel.org, Alejandro Colomar , Alejandro Colomar Subject: Re: [PATCH] strcat.3: SYNOPSIS: Fix the size of 'dest' In-Reply-To: <20221205151102.13042-1-alx@kernel.org> (Alejandro Colomar via Libc-alpha's message of "Mon, 5 Dec 2022 16:11:03 +0100") Organization: The Eyrie References: <20221205151102.13042-1-alx@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Mon, 05 Dec 2022 09:48:40 -0800 Message-ID: <87pmcx4u87.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Alejandro Colomar via Libc-alpha writes: > I'm continuing my indiscriminated shooting against broken functions. > I don't remember if I ever used it, but it got me surprised for how much > broken it is. > Please kill this function in glibc. The updated prototype using a bit > of imagination to overextend VLA syntax to show how it behaves, shows > how broken it is. > It is impossible to use this function correctly (okay, it you try hard, > you can, but only for the pleasure of using it without crashing, not for > anything useful). Hi Alejandro, I'm just a bystander here, but I've seen a few proposals like this go by, and I'm not sure anyone has yet said explicitly that these functions are incredibly widely used in real C code out in the world. They predate all of the functions that you are recommending as replacements for them, so they're common in old, portable C. I think the work you're doing to document that they should never be used for new code in the man pages is great; please continue! Although it may be useful to carry with that some caveats about portability; some of the replacements you've mentioned are going to pose portability challenges. I'm a bit more dubious about glibc marking these functions as formally deprecated unless the C standard also deprecates them (as happened with gets, which is probably the best precedent for what you're trying to accomplish). For the record, there is quite a lot of code out there that uses strcpy and strcat safely, using a pattern where first the total length of the resulting string is calculated, that much space is allocated, and then it is assembled with strcpy and strcat. This used to be the standard way to assemble strings in C before strlcpy or asprintf existed (and neither of those functions are all that portable even now; I would still hesittate to use either without a configure probe and a replacement implementation). I think you're exaggerating the difficulty of using them safely a tiny bit, but maybe that's just because I'm an old C programmer for whom that pattern is a finger macro. It's also probably worth saying explicitly that strlcpy and strlcat are still quite dangerous functions and need to be used very carefully. They do solve the problem of buffer overflows when used properly, but they replace that problem with silent truncation, which can also cause security vulnerabilities in the right circumstances. -- Russ Allbery (eagle@eyrie.org)