bug in __gmp_replacement_vsnprintf

[Marc Glisse]

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)
+5 because 'g' as +3 and 'a' has the extra "0x"

?
I would probably write +10 to have more margin, but I'd rather someone who 
understands these things give me the answer...


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.

-- 
Marc Glisse