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 960C73858D33 for ; Mon, 20 Mar 2023 17:45:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 960C73858D33 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 1peJZq-001GY9-2b; Mon, 20 Mar 2023 18:45:46 +0100 Date: Mon, 20 Mar 2023 18:45:46 +0100 From: Vincent Lefevre To: libc-alpha@sourceware.org Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230320174546.GI203866@cventin.lip.ens-lyon.fr> Mail-Followup-To: Vincent Lefevre , libc-alpha@sourceware.org References: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> <20230320150929.GA283644@cventin.lip.ens-lyon.fr> <20230320170031.GG203866@cventin.lip.ens-lyon.fr> 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=-2.4 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 13:31:33 -0400, Siddhesh Poyarekar wrote: > In glibc we tend to skip a test as UNSUPPORTED when resources to run a test > are considered uncommon (from the perspective of a test system) and cannot > be expected to be met in all environments. In MPFR, we have some tests that need much memory, which are enabled only if the MPFR_CHECK_LARGEMEM environment variable is set. But this means that some issues would not be detected on particular platforms by end users (MPFR_CHECK_LARGEMEM is mainly for developers). > It looks like mpfr_snprintf and glibc snprintf are incompatible in this > context and the latter should not be used to implement the former if the n > > __bos(dest) use case is important to it. > > Then again, I wish mpfr_snprintf also similarly tightened its requirements, > but that's a discussion for another day. Well, if the C standard is changed, I suppose that we will align to it. We can still recommend not to use n > buffer size if this is not supported by snprintf (even though the MPFR code is currently guaranteed to work in this case). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)