bug in __gmp_replacement_vsnprintf

[Paul Zimmermann]

thank you Marc, this is highly appreciated!

Paul

> Date: Fri, 31 Jan 2025 21:57:33 +0100 (CET)
> From: Marc Glisse <marc.glisse at inria.fr>
> cc: gmp-bugs at gmplib.org
> 
> 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
> _______________________________________________
> gmp-bugs mailing list
> gmp-bugs at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-bugs