UB status of snprintf on invalid ptr+size combination?

[Simon Chopin <simon.chopin@canonical.com>]

Hi,

We've come across a couple of regressions[0] in 2.37 on armhf due to a
peculiar use of snprintf that boils down to this:

char [32]buf;
...
snprintf(buf, INT_MAX, "%s", "Hello world");

This used to work fine, but now fails in a non-obvious way: the return
value is the one you would expect from a successful call (here, 11), but
the last character is overwritten by a NUL terminator.

It's likely the new behavior has been introduced by

commit e88b9f0e5cc50cab57a299dc7efe1a4eb385161d
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Dec 19 18:56:54 2022 +0100

    stdio-common: Convert vfprintf and related functions to buffers

We're hitting the issue because buf+INT_MAX overflows on armhf (being
32-bit and on the stack).

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.

Do you think it worth it to try and fix this regression? Florian
suggested an approach similar to

commit 0d50f477f47ba637b54fb03ac48d769ec4543e8d
Author: Florian Weimer <fweimer@redhat.com>
Date: Wed Jan 25 08:01:00 2023 +0100

    stdio-common: Handle -1 buffer size in __sprintf_chk & co (bug 30039)


Thanks in advance,
Simon

[0]: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2011326
[1]: https://bugs.launchpad.net/ubuntu/+source/notcurses/+bug/2008108

--
Simon Chopin
Foundations Team                               	    Ubuntu MOTU/Core Dev
simon.chopin@canonical.com                            schopin@ubuntu.com