On Fri, 28 Nov 2025, LIU Hao wrote:
When `%.d` is passed an argument of 0, it should not produce any digits. The
printf128 path uses an intermediate numeric string, which, in this case,
shall be truncated to an empty string. Old code left least one digit so it
erroneously produced "0".
This error was observed in one test in MPFR.
Signed-off-by: LIU Hao <[email protected]>
---
mingw-w64-crt/stdio/mingw_pformat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/stdio/mingw_pformat.c
b/mingw-w64-crt/stdio/mingw_pformat.c
index 317dfe985..fc7429ba4 100644
--- a/mingw-w64-crt/stdio/mingw_pformat.c
+++ b/mingw-w64-crt/stdio/mingw_pformat.c
@@ -775,7 +775,7 @@ void __pformat_int( __pformat_intarg_t value, __pformat_t
*stream )
*/
__bigint_to_string(value.__pformat_u128_t.t128_2.digits32,
4, tmp_buff, bufflen);
- __bigint_trim_leading_zeroes(tmp_buff,1);
+ __bigint_trim_leading_zeroes(tmp_buff, 0);
memset(p,0,bufflen);
for(int32_t i = strlen(tmp_buff) - 1; i >= 0; i--){
--
I can't say I'm familiar with the code here so I can't say I know for sure
by looking at this diff - but if you say that this fixes conformance
observed in other testsuites (that passed without the print128 codepaths
enabled), I guess it's ok.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
