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 AB82B3858413 for ; Mon, 20 Mar 2023 15:09:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB82B3858413 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 1peH8b-001EUJ-2m; Mon, 20 Mar 2023 16:09:29 +0100 Date: Mon, 20 Mar 2023 16:09:29 +0100 From: Vincent Lefevre To: libc-alpha@sourceware.org Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230320150929.GA283644@cventin.lip.ens-lyon.fr> Mail-Followup-To: Vincent Lefevre , libc-alpha@sourceware.org References: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> 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=-2.9 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-19 10:45:59 -0400, manfred via Libc-alpha wrote: > All of that said, back to the OP case I would not pass INT_MAX to snprintf. > If I have a situation wherein I know that the buffer is large enough, but I > don't know its exact size, I'd use sprintf and be done with it. (I'm sure > that the actual code is more elaborate than this, but still) Here's another example where the support of snprintf with a large n argument (larger than the buffer size) may be used: In GNU MPFR, for our function mpfr_snprintf, we have assumed a behavior analogue to the ISO C behavior. In particular, we use that in our tests in order to check that large values of n are correctly handled. This allowed us to trigger/detect a bug in the choice of the integer types in our implementation: The test: https://gitlab.inria.fr/mpfr/mpfr/-/commit/67a75bfe41d3a7f95367ee9e62bd7dfc73e5b395 The bug fix (replacing an int by a size_t in a variable declaration): https://gitlab.inria.fr/mpfr/mpfr/-/commit/6b8cf3e2bdc285027627281cac230ed932c1b73f Note that the MPFR code currently does not use snprintf or any similar function, so that there should be no issues with this test if snprintf does not support n > buffer size, it but may use such a function in the future. (Indeed, MPFR currently uses gmp_vasprintf and gmp_asprintf, thus generating a full output before truncating it as needed, so that this is potentially very inefficient and could unnecessarily exhaust the memory and/or crash.) -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)