From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cventin.lip.ens-lyon.fr (cventin.lip.ens-lyon.fr [140.77.13.17]) by sourceware.org (Postfix) with ESMTPS id 7DAA1385840D for ; Mon, 20 Mar 2023 13:50:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DAA1385840D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vinc17.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=vinc17.net Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.96) (envelope-from ) id 1peFuO-001BF2-2G; Mon, 20 Mar 2023 14:50:44 +0100 Date: Mon, 20 Mar 2023 14:50:44 +0100 From: Vincent Lefevre To: libc-alpha@sourceware.org Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230320135044.GB203866@cventin.lip.ens-lyon.fr> Mail-Followup-To: Vincent Lefevre , libc-alpha@sourceware.org References: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> <20230319230722.GD390223@zira.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.9+71 (caea3018) vl-149028 (2023-03-14) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP 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: On 2023-03-20 08:05:32 -0400, Siddhesh Poyarekar wrote: > I think on the glibc front it makes sense from a security > perspective to interpret this through POSIX than the C standard. > Even if the C standard is clarified to be contrary to POSIX and > explicitly state that n is not the size of the buffer (which would > be a terrible mistake IMO), I'd lean towards violating the C > standard and conforming to POSIX instead. I disagree about the POSIX behavior (assuming it is intentional). With it, if the compiler detects that n is larger than the actual buffer size, then due to undefined behavior, the compiler could assume that this is dead code and introduce erratic behavior in code written with the C standard in mind (or when it was introduced in BSD). Note that the printf(3) man page from FreeBSD 1.0 (1991), just says: Snprintf() and vsnprintf() will write at most size-1 of the characters printed into the output string (the size'th character then gets the terminating `\0'); if the return value is greater than or equal to the size argument, the string was too short and some of the printed characters were discarded. Reference: https://man.freebsd.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=0&manpath=FreeBSD+1.0-RELEASE&arch=default&format=html -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)