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

[Vincent Lefevre <vincent@vinc17.net>]

On 2023-03-18 03:30:27 +0100, Alejandro Colomar wrote:
> Hello Vincent,
> 
> On 3/18/23 03:07, Vincent Lefevre wrote:
> > 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.
> 
> I guess you mean the minimum?  If it were the maximum, then it would
> never truncate.

Yes, obviously, the minimum.

> [assuming you meant minimum]:
> 
> As Andreas mentioned, that's valid for ISO C, but POSIX is more
> restrictive.  Here's a quote from fprintf(3posix):
> 
>        The snprintf() function shall be equivalent to sprintf(),  with
>        the  addition  of  the  n argument which states the size of the
>        buffer referred to by s.
> 
> It clearly specifies that 'n' is the size of the buffer, so
> implementations are free to assume that `s+n` is a valid pointer.

However, I'm wondering whether such a change is intentional. BTW,
this description is even wrong: this is certainly not equivalent!
If the untruncated output is larger than n, then the call is UB
with sprintf(), while the output is truncated with snprintf(). What
really occurs is described later, but still, this first sentence is
incorrect. This could just mean that they tried to oversimplify when
writing this text, without thinking of the details.

> > 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.
> 
> The size argument to strncpy(3) is the size of the destination buffer,
> not the size of the input buffer.  The input buffer must be either
> a string, or a character sequence at least as large as the destination
> buffer.  Thus, in strncpy(3), reads are limited by
> `strnlen(src, size)`, but writes are limited by `size`.

I agree, but I was answering to Stephan Bergmann, who thought that
a size_t argument could be seen as the size of the array arguments.
IMHO, the (minimum) sizes of the arrays are just implied from the
described behavior of the function.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)