Re: [PATCH] correct %g handling with unknown arguments in -fprintf-return-value (PR 78696)

[Martin Sebor <msebor@gmail.com>]

>> +    /* The lower bound when precision isn't specified is 8 bytes
>> +       ("1.23456" since precision is taken to be 6).  When precision
>> +       is zero, the lower bound is 1 byte (e.g., "1").  Otherwise,
>> +       when precision is greater than zero, then the lower bound
>> +       is 2 plus precision (plus flags).  */
>> +    res.range.min = (flagmin
>> +             + (prec != INT_MIN)   /* for decimal point */
>> +             + (prec == INT_MIN
>> +                ? 0 : prec < 0 ? 6 : prec ? prec : -1));
> Note for the future, nest/chained ternary operators can sometimes just
> be hard to visually parse when they're squashed on a single line.
> Formatting like this has often been used in the past to help clarify the
> intent:
>
> (flagmin
>  + (prec != INT_MIN)
>  + (prec == INT_MIN ? 0
>     : prec < 0 ? 6
>     : prec ? prec
>     : -1)

Okay.

>
> If we ignore the flagmin component, I get the following evaluations for
> PREC.
>
> PREC                       RESULT
> INTMIN                       0
> 0                          0
> negative (but not INTMIN)  7
> positive                   prec + 1
>
> That doesn't seem in-line with the comment.

Sorry, I think I need a hint.  Which part doesn't seem in line with
which part of the comment?  The numbers you have look correct to me
and I don't see anything wrong with the comment either.

Flagmin is always at least 1 and so RESULT above is 1 when precision
is used and either zero or unknown (because printf ("%.0f", 0) returns
1), and it's 8 when precision is negative because it's taken as if had
been omitted (i.e., it's 6 and printf ("%f", 0) formats "0.000000" and
returns 8), and it's prec + 2 when precision is positive because the 2
accounts for the leading "0." (when argument is zero) and precision is
the number of fractional digits.

Martin

PS While testing this I came across a bug in MPFR.  When precision is
large it allocates huge amounts of memory and appears to get stuck in
some sort of a loop (e.g., with sprintf(d, "%.*g", INT_MAX)).  I've
tested the diff below to work around it.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 3d34342..c39b318 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1170,8 +1170,27 @@ format_floating_max (tree type, char spec, int prec)

    if (-1 < prec)
      {
-      const char fmt[] = { '%', '.', '*', 'R', spec, '\0' };
-      n = mpfr_snprintf (NULL, 0, fmt, prec, x);
+      /* Prevent MPFR from allocating too much memory.  */
+      if (TOUPPER (spec) == 'G')
+       {
+         /* For G/g, precision gives the maximum number of significant
+            digits which is bounded by LDBL_MAX_10_EXP, or, for a 128
+            bit IEEE extended precision, 4932.  Using twice as much
+            here should be more than sufficient for any format.  */
+         int p = 9864 < prec ? 9864 : prec;
+         const char fmt[] = { '%', '.', '*', 'R', spec, '\0' };
+         n = mpfr_snprintf (NULL, 0, fmt, p, x);
+       }
+      else
+       {
+         /* Cap precision at 1KB and add the difference to the MPFR
+            result.  */
+         int p = 1024 < prec ? 1024 : prec;
+         const char fmt[] = { '%', '.', '*', 'R', spec, '\0' };
+         n = mpfr_snprintf (NULL, 0, fmt, p, x);
+         if (p < prec)
+           n += prec - p;
+       }
      }
    else
      {