Re: UB status of snprintf on invalid ptr+size combination?

[manfred <mx2927@gmail.com>]

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.
>