From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 68BC63858D33 for ; Tue, 14 Mar 2023 21:39:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68BC63858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4756D160076; Tue, 14 Mar 2023 14:39:44 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id y8Ssah6T4njf; Tue, 14 Mar 2023 14:39:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6255C16007D; Tue, 14 Mar 2023 14:39:43 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 6255C16007D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1678829983; bh=sPVYfyGYRlFyP4p3SDp1lBaLCfyn+5R+JAb80mlqc/Y=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=ijzSpXsnyCg0nPQS71HspyeW2My6sDIkfPKFQAVNOVqizAPoz1k+GPowlXdAUZSOb nKP2pWlLMTr2VUtc2RqGEQn3whZ1/c+jjdtxCARi0inVJnoZcXpgWM0mKx7XTdK+zW KFDceROZ+57qSssghT6RfzYjZb2OytDBXKPRaJNU= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id meUysJpKQ-1X; Tue, 14 Mar 2023 14:39:43 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3DA60160076; Tue, 14 Mar 2023 14:39:43 -0700 (PDT) Message-ID: Date: Tue, 14 Mar 2023 14:39:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: UB status of snprintf on invalid ptr+size combination? Content-Language: en-US To: Simon Chopin References: From: Paul Eggert Organization: UCLA Computer Science Department Cc: libc-alpha@sourceware.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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 3/14/23 12:47, Simon Chopin via Libc-alpha wrote: > When the issue was first discovered[1], I didn't raise the issue because I > dismissed it as UB, but it reappeared in an unrelated context, and > colleagues pointed out that the wording in the standard doesn't actually > say that the `n` argument is the size of the array. That sounds like a misreading of the C standard. Even though the standard often does not explicitly say that a size argument is the size of an array, it's obvious from context that this is intended. So Florian is correct here that the call with INT_MAX is not portable C code. 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 = buf + size; ... } even though this would have undefined behavior if BUF points to a character array smaller than SIZE. glibc snprintf does the equivalent of the above internally, so it's a good thing that notcurses has been fixed to not use the INT_MAX trick as that trick already did not work in general with glibc and I assume with other C libraries (with rare and hard-to-diagnose failures), even aside from any fortification business that made the bug more visible.