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

[Vincent Lefevre <vincent@vinc17.net>]

On 2023-03-20 12:56:34 -0400, Siddhesh Poyarekar wrote:
> On 2023-03-20 09:50, Vincent Lefevre wrote:
> > On 2023-03-20 08:05:32 -0400, Siddhesh Poyarekar wrote:
> > > I think on the glibc front it makes sense from a security
> > > perspective to interpret this through POSIX than the C standard.
> > > Even if the C standard is clarified to be contrary to POSIX and
> > > explicitly state that n is not the size of the buffer (which would
> > > be a terrible mistake IMO), I'd lean towards violating the C
> > > standard and conforming to POSIX instead.
> > 
> > I disagree about the POSIX behavior (assuming it is intentional).
> 
> Why do you think it may be unintentional?

Yes, because it does not warn about a difference with the C standard
(and see below...).

> The POSIX wording seems pretty deliberate and clear to me.

Standards may have clear text, while some corner cases have been
overlooked. This occurs frequently. As an example, see

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
  (LDBL_MAX is incorrect with IBM long double format)

and a DR eventually changed the definition, even though it was clear:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399#c4

Note: This change of definition was not much an issue in practice
because it made the standard match the actual implementations
(probably all of them). So it did not break anything.

Back to POSIX: The text was probably written like that because in
almost all the cases, n is a valid size of the array and the change
of formulation made the text a bit simpler. But this broke some
legitimate uses, and at that time, the working group may not have
been aware of that. It would be useful to know whether this had been
brought in the discussions at that time.

> The C standard wording on the other hand leaves things to the
> imagination, which is why we're having this discussion.

What things to the imagination? IMHO, the C standard wording is very
clear.

> > With it, if the compiler detects that n is larger than the actual
> > buffer size, then due to undefined behavior, the compiler could
> > assume that this is dead code and introduce erratic behavior in
> > code written with the C standard in mind (or when it was introduced
> > in BSD).
> 
> In fact, with _FORTIFY_SOURCE, if the runtime detects that n is larger than
> the actual buffer size, the code will abort, see pr28989[1].  But that's a
> runtime feature, nothing to do with gcc.
> 
> gcc at the moment doesn't have any such check AFAICT but if it does, I
> reckon that's a discussion to be had on the gcc mailing list.

If the ISO C standard is meant to be changed, all compilers could
potentially consider the code as dead code, not just GCC.

IMHO, it would be very bad to consider the code as UB. It would be
better to standardize _FORTIFY_SOURCE (that would add restrictions,
but with a controlled behavior).

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