bug in __gmp_replacement_vsnprintf

[Vincent Lefevre]

On 2025-01-29 21:53:24 +0100, Marc Glisse wrote:
> On Wed, 12 Oct 2022, Paul Zimmermann wrote:
> 
> > The issue is because __gmp_replacement_vsnprintf does not deal with %a not %A.
> > Then when calling gmp_printf ("%a", -1.25) for example, we get total_width=3
> > initially, we jump to the 'default' case, where the ASSERT(0) does nothing
> > in production code, and we go to next, where width=0 and prec=6, thus
> > total_width is increased to 9. But we also have len=9 because
> > buf='-0x1.4p+0'. Then the assertion ASSERT_ALWAYS (len < total_width) fails.
> 
> Hi Paul,
> 
> indeed, '%a' does not seem to be handled. Do you know what an appropriate
> upper bound on the size of the output would be?
> 
> Trying to guess from the handling of 'f', 'g', etc:
> total_width += prec + 5 + floating_sizeof * 2;
> 
> *2 because a byte (8 bits) only needs 2 hex (4 bits)

You also need to take the exponent into account. If the exponent
takes k bits, this would be of the order k * log(2)/log(10). So,
if the exponent takes n bytes, this would be of the order
8n * log(2)/log(10) ≈ 2.4 n.

So, instead of *2, you could choose *5/2 (2.5 being larger than
8 * log(2)/log(10)).

> +5 because 'g' as +3 and 'a' has the extra "0x"

The sign + "0x" + "p" + the sign of the exponent also give 5.

But this assumes that you did not have width and precision fields.

> Other than that, it feels wrong that this replacement function is still used
> on some windows configurations, visual studio has had vsnprintf for a long
> time now. There is also the possibility of using gnulib's version of
> vsnprintf if we don't want to maintain our own, but I think I'd rather make
> configure fail on missing vsnprintf to force users to configure their
> toolchain properly.

IIRC, the issue is that the version is MS Windows is buggy.

This is no longer an issue in MinGW, where __USE_MINGW_ANSI_STDIO
is now defined by default, if I understand correctly.

GMP's vsnprintf is also used under OpenBSD 7+, which does not
support %n.

But I would say that it would be OK to consider that broken features
in the system vsnprintf would also affect GMP, as long as they do not
affect the specifiers with GMP types.

-- 
Vincent Lefèvre <vincent at 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)