From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by sourceware.org (Postfix) with ESMTPS id 647B33858C78 for ; Wed, 15 Mar 2023 18:34:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 647B33858C78 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=canonical.com Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 059983F201 for ; Wed, 15 Mar 2023 18:34:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1678905285; bh=7xzxzKd0eKwB0s9vvU0+jwB03Sq9Ec2HkCWyL4WxDeg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AL/+fNprD8CcDBDxfibls+N8mgpqXImbGPeCG+43ig39ZcFj2PCZU7lVPZwwXpbyK HrcPweWyIGiulIlsPjE+QApoq/DRmZTb1/NKvN2y8UTUX86TBIvzE70xZjUwOx/xw+ Bn1ENUTCA43/nyMFGVVQ5FzBmLg2e/Np6NnDIdKIvkvkwX32AvZe07rywXaQW0QEFW akH8mexrPMByGP1MBNS9jTUo/gfWtDx/s2aNgwmUM7NxrrV9BWiDCjM96gYIECzcrJ yTm4w98Z86Q6+l9ziqRV2LyJnvMlcSQBbEAsLTZ06d6WxVwTmPIMwbJJFohQkxC4Cd wRD0jrqjJqpcw== Received: by mail-pl1-f199.google.com with SMTP id l1-20020a170903244100b001a0468b4afcso5538832pls.12 for ; Wed, 15 Mar 2023 11:34:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678905283; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7xzxzKd0eKwB0s9vvU0+jwB03Sq9Ec2HkCWyL4WxDeg=; b=Ev37xLERIRzchpbtHAKHnGq0VaAepS+GYdiGSXgOQvrP9n0oNXIgvpIBzh0ddGTif6 vSPzoQfzwh8l6Y8XknqfkgPxdSDyAtZFallEcgqj9tBMqQ1Tv1TSWhKRwdy7Y8y1jjpY KZO+k4CkxnlsiTNk/25QUu/SZggZzecdGRPgDZlJQLczBYNqeyPVLcdWcxADqDhHu4mN KY/iKhqzjMRT41bUPMrztGtSYjLUDfXh+NmzxZaZAne7Kvejjks114W281M5inQOpbs3 XcucuWn40LJY1WCOmDkfE5DMPTkfYcgu4rumm9nzO0iXtVCtbW875JEI5g2u4JtUWeOu 2l3A== X-Gm-Message-State: AO0yUKWVfaaqOZWprgQx5Ui0HXZJQsTI3Q6U7dH6CJ+v1p1PJ+B4c2Dt KmvaagjTfm0qnL2HRcWTi3AuggjVbVf8UkJ/WJj39J4DzPI+vKHARMFDdBDd9xW6Jv/x+tEIM0g LIqDeGlFlWrtltuuWrdOpiWKSBL+JXfBy1RBKhGyJwvzcFcu430HB4g== X-Received: by 2002:a17:902:ce88:b0:194:6fc0:aaae with SMTP id f8-20020a170902ce8800b001946fc0aaaemr223566plg.6.1678905283430; Wed, 15 Mar 2023 11:34:43 -0700 (PDT) X-Google-Smtp-Source: AK7set8adcpvSdLdrR1bh+waYps4Thst9vsu9YBxjfG3a8dakBf1pPF/NOCyfU6SgMhAzflzT66/cZGGRoh3e6Yh6iE= X-Received: by 2002:a17:902:ce88:b0:194:6fc0:aaae with SMTP id f8-20020a170902ce8800b001946fc0aaaemr223552plg.6.1678905283127; Wed, 15 Mar 2023 11:34:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Hudson-Doyle Date: Thu, 16 Mar 2023 07:34:31 +1300 Message-ID: Subject: Re: UB status of snprintf on invalid ptr+size combination? To: Andreas Schwab Cc: Paul Eggert , Simon Chopin , libc-alpha@sourceware.org Content-Type: multipart/alternative; boundary="00000000000003438a05f6f49966" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000003438a05f6f49966 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 15 Mar 2023 at 22:22, Andreas Schwab via Libc-alpha < libc-alpha@sourceware.org> wrote: > On M=C3=A4r 14 2023, Paul Eggert wrote: > > > For example, it's valid for snprintf to be implemented this way: > > > > int > > snprintf (char *buf, size_t size, char const *fmt, ...) > > { > > char *buf_limit =3D buf + size; > > ... > > } > > > > even though this would have undefined behavior if BUF points to a > > character array smaller than SIZE. > > Since it is part of the implementation it is irrelevant from the POV of > the standard. The implementation does not have to abide to the C > standard, as long as it properly implements the interface constraints. > > What matters is the wording of the standard. The POSIX standard is more > explicit here: "with the addition of the n argument which states the > size of the buffer referred to by s." Probably the C standard should be > clarified. > Ah that's interesting that POSIX is clearer here, thanks for pointing that out. I can feel more confident declaring the affected code broken now :-) Is anyone here close enough to the C standards process to push getting this clarified there? Cheers, mwh --00000000000003438a05f6f49966--