From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from joooj.vinc17.net (joooj.vinc17.net [IPv6:2001:4b99:1:3:216:3eff:fe20:ac98]) by sourceware.org (Postfix) with ESMTPS id E99BD3858C53 for ; Mon, 20 Mar 2023 04:11:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E99BD3858C53 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 smtp-zira.vinc17.net (128.119.75.86.rev.sfr.net [86.75.119.128]) by joooj.vinc17.net (Postfix) with ESMTPSA id 0004E682; Mon, 20 Mar 2023 05:10:57 +0100 (CET) Received: by zira.vinc17.org (Postfix, from userid 1000) id 8A9322800238; Mon, 20 Mar 2023 05:10:57 +0100 (CET) Date: Mon, 20 Mar 2023 05:10:57 +0100 From: Vincent Lefevre To: Andreas Schwab Cc: Alejandro Colomar , libc-alpha@sourceware.org, Stephan Bergmann , Paul Eggert , Simon Chopin Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230320041057.GE390223@zira.vinc17.org> Mail-Followup-To: Vincent Lefevre , Andreas Schwab , Alejandro Colomar , libc-alpha@sourceware.org, Stephan Bergmann , Paul Eggert , Simon Chopin References: <20230315123949.GC73312@zira.vinc17.org> <92810b6e-e7e6-6ffd-d33a-067b9f300059@redhat.com> <20230318020725.GA15308@zira.vinc17.org> <9c8cae93-cb8c-8689-1f0e-2b87514d3702@gmail.com> <20230318105827.GB15308@zira.vinc17.org> <875yayyuh8.fsf@igel.home> <20230319224809.GC390223@zira.vinc17.org> <87ilewiat8.fsf@igel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ilewiat8.fsf@igel.home> 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=-1.5 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 00:24:51 +0100, Andreas Schwab wrote: > On Mär 19 2023, Vincent Lefevre wrote: > > > On 2023-03-18 16:01:07 +0100, Andreas Schwab wrote: > >> On Mär 18 2023, Vincent Lefevre wrote: > >> > >> > However, I'm wondering whether such a change is intentional. BTW, > >> > this description is even wrong: this is certainly not equivalent! > >> > If the untruncated output is larger than n, then the call is UB > >> > with sprintf(), while the output is truncated with snprintf(). > >> > >> Which makes them equivalent in all situations where sprintf is defined, > >> so there is no discrepancy here. > > > > The conditions under which the function is defined or not are part of > > the equivalence. > > No, it isn't. Equivalent is not the same as identical. > > > For instance, I would not say that memcpy and memmove are equivalent, > > even though they are equivalent when memcpy is defined. > > But they are. You can use either memcpy or memove in all situations > where memcpy is defined. Outside of the domain of memcpy there is no > relation at all. POSIX specifies _exit() by: The _Exit() and _exit() functions shall be functionally equivalent. So, you mean that _exit() may have undefined behavior while _Exit() has a well-defined behavior? (as this would match your definition of equivalence.) -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)