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 F0CDB3858C50 for ; Sat, 18 Mar 2023 02:07:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0CDB3858C50 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 3DB361E5; Sat, 18 Mar 2023 03:07:26 +0100 (CET) Received: by zira.vinc17.org (Postfix, from userid 1000) id CB9D92800197; Sat, 18 Mar 2023 03:07:25 +0100 (CET) Date: Sat, 18 Mar 2023 03:07:25 +0100 From: Vincent Lefevre To: Stephan Bergmann Cc: libc-alpha@sourceware.org, Paul Eggert , Simon Chopin Subject: Re: UB status of snprintf on invalid ptr+size combination? Message-ID: <20230318020725.GA15308@zira.vinc17.org> Mail-Followup-To: Vincent Lefevre , Stephan Bergmann , libc-alpha@sourceware.org, Paul Eggert , Simon Chopin References: <20230315123949.GC73312@zira.vinc17.org> <92810b6e-e7e6-6ffd-d33a-067b9f300059@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <92810b6e-e7e6-6ffd-d33a-067b9f300059@redhat.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/2.2.9+69 (3263c953) vl-149028 (2023-03-13) X-Spam-Status: No, score=-1.7 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-16 11:29:31 +0100, Stephan Bergmann wrote: > On 15/03/2023 13:39, Vincent Lefevre wrote: > > No, it is not obvious. If the C standard does not say that this is > > the size of the array, then it does not have to be the size of the > > array. The C standard just says: > > > > Otherwise, output characters beyond the n-1st are discarded rather > > than being written to the array, and a null character is written at > > the end of the characters actually written into the array. > > But in 7.1.4 "Use of library functions" the standard also says > > > If a function argument is described as being an array, the pointer > > passed to the function shall have a value such that all address > > computations and accesses to objects (that would be valid if the > > pointer did point to the first element of such an array) are > > valid. > > which could be construed as meaning that the n-1st array element must always > be accessible, even if a given invocation is known to always generate less > then n output characters. But the standard does not say that n is the size of the array. The size of the array could be the maximum of n and the size corresponding to the untruncated output string. Similarly, for strncpy, I would not see n as the size of the arrays, i.e. it is not allowed for the implementation to read characters past a null character (possibly unless this does not have unwanted effects), even though such characters would be among the first n characters. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)