bug in __gmp_replacement_vsnprintf

[Marc Glisse]

Thank you for those precisions.

I pushed something, not perfect but the MPFR testsuite seems ok with it.

There are still a number of things not handled in this replacement 
function. If people want them fixed, please provide patches, I don't 
intend to waste more time on it.

On Thu, 30 Jan 2025, Vincent Lefevre wrote:

> 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)
> _______________________________________________
> gmp-bugs mailing list
> gmp-bugs at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-bugs

-- 
Marc Glisse