From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id 24B853858D1E for ; Sun, 19 Mar 2023 14:46:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24B853858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x835.google.com with SMTP id t9so10490659qtx.8 for ; Sun, 19 Mar 2023 07:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679237161; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=9grx5IX4tdJmKuxZ9EiMGj1CiZipsuWfskj7JzANXeg=; b=BC0ijDOdtvzQ7ehWG7zhvA33nXoDytcuq2d7K5dMkDlBbku0Rn59cGCBuPUUBRBVhY /8xIxOIZb/QC4oaQYglU9dtdQw75rFoNbG16hut7jH5ykjOiyPz3tw5hS/U1SCXhaAqP J7uK7D6LTIfZCMXe4j8hOQOMIG3V0QzSfemo3wPX9Ud5qUP4VpXEqQ2srBWvww5iAR8M JrgsQ349khwcRTnGStkOvfRS51USI9XrSyx+7AUHclgs1NJk1/wrM18vwruen9ybhGEk h/Di6/w+jXxYfczY2RFLosHAW9/cfUNkttGQh7QUXqYr+OM4H2O594/zJ0P/VrDK7UJG 6WUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679237161; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9grx5IX4tdJmKuxZ9EiMGj1CiZipsuWfskj7JzANXeg=; b=l+LhdOEz8JQjTAhefV/EQgSpAuzHDkkEJIlnDwjYpHePKm1+54a4Q2/1oFxrr1BjMZ cXeNWR0cgJqPL7+7Bje/V/72nrf58vPzbRaHj8wZnY+yjDa0OYRoHHivPBATuLbI+l91 3Fht/fSO9l8fzegt96zQqi7L7WhYOyu/hQ/8663ot4GEEGSa44iiZEXWydL9N+h73RZ0 v0Jq463iij5x1+rFiNeI9vJ9sGfPcRE5fWcn5QXipbkPCaxvcq2oCeYDg8EEOA03G1ys nUtsTvUYvqsjfv8eaQsYKwvx/jVaApqRaqqimcUk8/CjWc/1gmddIzvYm0+so2dLHikm vcCQ== X-Gm-Message-State: AO0yUKWl8gu2GbZJiLbxlKIjNW9PCER8L8vLLSffceyk4UHACkApJxy8 dMN/OahEfv39byAeJkpyisUT6Za6Aig= X-Google-Smtp-Source: AK7set/Id7BJHjvkNM3zjxwGVCUvROl6ScaHy7YKjctA2kMMnPuqf8b2q6cUlZa6T+LXNAQqXMvQZQ== X-Received: by 2002:ac8:5a06:0:b0:3d9:742a:a7a with SMTP id n6-20020ac85a06000000b003d9742a0a7amr16121573qta.37.1679237160999; Sun, 19 Mar 2023 07:46:00 -0700 (PDT) Received: from ?IPV6:2601:703:200:3a60:9017:d38c:2c79:316e? ([2601:703:200:3a60:9017:d38c:2c79:316e]) by smtp.gmail.com with ESMTPSA id cc24-20020a05622a411800b003d4e84a55f9sm4746914qtb.92.2023.03.19.07.46.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Mar 2023 07:46:00 -0700 (PDT) Message-ID: <9d7ca3d8-6998-e741-b669-03ef42bc99f1@gmail.com> Date: Sun, 19 Mar 2023 10:45:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 From: manfred Subject: Re: UB status of snprintf on invalid ptr+size combination? To: libc-alpha@sourceware.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: After reading it a few times, I believe that the meaning of the wording of the ISO C standard is that 'n' is an upper limit to the number of characters written to s, not necessarily the size of the array. Also, the standard says that "The snprintf function is equivalent to fprintf, except that the output is written into an array (specified by argument s) rather than to a stream" Which implies that no access to the output array is performed after termination of encoding, regardless of the actual value of n. To me, it looks like in this case, i.e. when the encoded result is shorter than the array size and n, the distinction between n being the actual array size, or an upper limit to the length of the output string, is only relevant to the implementation: The question becomes: is the implementation allowed to access elements past the encoded result? Is it allowed to evaluate s+n? Out of curiosity, I compared the wording with the specifications in Annex K, which is explicitly aimed at checking array boundaries: as far as I can tell snprintf_s refers to snprintf, and does not add to this scenario. sprintf_s says about n: "n shall neither equal zero nor be greater than RSIZE_MAX. The number of characters (including the trailing null) required for the result to be written to the array pointed to by s shall not be greater than n." Again, this describes an upper limit to the length of the result, not the array size, but next in the description: "4 The sprintf_s function is equivalent to the sprintf function except for the parameter n and the explicit runtime-constraints listed above. 5 The sprintf_s function, unlike snprintf_s, treats a result too big for the array pointed to by s as a runtime-constraint violation." In this last sentence, the expression "a result too big for the array" hints at the array size (otherwise it should say "a result longer than n"), but propagating this to the rest of the text requires some imagination about the intention of the authors. All of that said, back to the OP case I would not pass INT_MAX to snprintf. If I have a situation wherein I know that the buffer is large enough, but I don't know its exact size, I'd use sprintf and be done with it. (I'm sure that the actual code is more elaborate than this, but still) My 2c On 3/15/2023 5:22 AM, Andreas Schwab via Libc-alpha wrote: > On Mär 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 = 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. >