[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260721222838.GY27423@brightrain.aerifal.cx>
Date: Tue, 21 Jul 2026 18:28:39 -0400
From: Rich Felker <dalias@...c.org>
To: Luca Kellermann <mailto.luca.kellermann@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] sprintf: fix one byte truncation when producing
string of length INT_MAX
On Tue, Jul 21, 2026 at 10:31:04PM +0200, Luca Kellermann wrote:
> (v)sprint() is supposed to return the number of bytes written to s,
> excluding the terminating null byte. however, when these functions
> return INT_MAX, only INT_MAX - 1 bytes (excluding the terminating null
> byte) are written.
>
> this is caused by the way vsprintf() is implemented: calling
> vsnprintf() with n = INT_MAX. vsnprintf() returns the number of bytes
> that would be written to s had n been sufficiently large excluding the
> terminating null byte. output bytes beyond the n-1st are discarded.
>
> to accommodate the largest strings (v)sprintf() can produce (length
> INT_MAX, the return value is of type int), vsnprintf() has to be
> called with n >= INT_MAX + 1.
>
> calling vsnprintf() with n > INT_MAX is possible since commit
> 11fb383275d20f5f94c00425bd888a02ecbd218e.
Thanks. Indeed, prior to this commit, there was no way for [v]sprintf
to handle this case right, since vsnprintf would reject the larger
size.
On 32-bit archs there was never a bug here, because objects of size
larger than INT_MAX can't exist. But indeed your test case
demonstrates the problem on 64-bit.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
