https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The g/G handling looks indeed totally broken, not just for the > 10 precisions,
even for %.9g it assumes it will be in between 11 and 13 characters, which is
of course wrong.
But even generally, for all floating point printing, it seems the code doesn't
take into account that various parts of the floating point printing are derived
from locale and might not always have the same size.
Consider:
#include <locale.h>
#include <stdlib.h>
int __attribute__ ((noinline))
foo (char *x, size_t y, double z)
{
return __builtin_snprintf (x, y, "%.2f", z);
}
int
main ()
{
char x[100], y[100];
setlocale (LC_ALL, "");
int ret = foo (x, 100, 1.5);
int ret2 = foo (y, 100, -1.5);
__builtin_printf ("%d\t%s\n%d\t%s\n", ret, x, ret2, y);
return 0;
}
This prints (with -fno-printf-return-value) in LC_ALL=C as well as
LC_ALL=en_US.UTF-8:
4 1.50
5 -1.50
in LC_ALL=cs_CZ.UTF-8:
4 1,50
5 -1,50
(note, comma used instead of dot, but still the same size), but with
ps_AF.UTF-8 it prints:
5 1٫50
6 -1٫50
because the Pashto decimal point character is U+066B, which is 2 bytes in
UTF-8.
For floating point printing, there can be also thousands grouping etc., again
locale specific.
