[Bug c/114374] New: [12/13 Regression] snprintf Wformat-truncation

[Bug c/114374] New: [12/13 Regression] snprintf Wformat-truncation

[torsten.mandel at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

            Bug ID: 114374
           Summary: [12/13 Regression] snprintf Wformat-truncation
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: torsten.mandel at sap dot com
  Target Milestone: ---

Source:

// ===========================================
#include "stdio.h"

int main() {
    char buf[11];
    int loop(1);
    do {
        snprintf(buf,sizeof(buf),"%d",loop++);
    } while(true);
}
// ===========================================


Compiled with: gcc -Wall

triggers:

./buffertest.cpp: In function ‘int main()’:
./buffertest.cpp:8:37: warning: ‘snprintf’ output may be truncated before the
last format character [-Wformat-truncation=]
    8 |         snprintf(buf,sizeof(buf),"%d",loop++);
      |                                     ^
./buffertest.cpp:8:17: note: ‘snprintf’ output between 2 and 12 bytes into a
destination of size 11
    8 |         snprintf(buf,sizeof(buf),"%d",loop++);
      |         ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

when using gcc-12 and gcc-13; gcc-11 compiled without error.

Replacing loop++ with ++loop does not trigger the error; neither case should be
an error as the overflow is UB in both cases and only positive numbers should
be considered regarding the target buffer size.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13 Regression] snprintf |[12/13/14 Regression]
                   |Wformat-truncation          |snprintf Wformat-truncation
   Target Milestone|---                         |12.4

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are invoking UD so a diagnostic is within that constraint.  Can you produce
a testcase without UD that still shows the issue?

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[torsten.mandel at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

--- Comment #2 from Torsten Mandel <torsten.mandel at sap dot com> ---
No, it only happens on overflow, although diagnostic behavior would still be
inconsistent regarding the ++loop and the loop++ case.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[torsten.mandel at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

--- Comment #3 from Torsten Mandel <torsten.mandel at sap dot com> ---
Sorry, actually it also triggers for values below LONG_MAX on gcc-12 & gcc-13
so it also works without UB which should not be the case.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[torsten.mandel at sap dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

--- Comment #4 from Torsten Mandel <torsten.mandel at sap dot com> ---
E.g.:

#include "stdio.h"
#include <climits>

int main() {
    char buf[11];
    int loop(1);
    do {
        snprintf(buf,sizeof(buf),"%d",loop++);
    } while(loop<10);
}

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-03-18
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

For some reason doing changing `loop++` to what it does manually does not warn:
That is for
```
void f() {
    char buf[11];
    int loop(1);
    do {
        __builtin_snprintf(buf,sizeof(buf),"%d",loop++);
    } while(loop<10);
}
void g() {
    char buf[11];
    int loop(1);
    do {
        int old = loop;
        loop++;
        __builtin_snprintf(buf,sizeof(buf),"%d",old);
    } while(loop<10);
}
```

f is being warned about but g is not.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems format_integer uses the ranger even at -O0, and asks the ranger there
(talking about #c5 at -O0 -Wall) for value of loop.0_1
1398          value_range vr;
1399          ptr_qry.rvals->range_of_expr (vr, arg, dir.info->callstmt);
in
  <bb 2> :
  loop_4 = 1;

  <bb 3> :
  # loop_2 = PHI <loop_4(2), loop_6(5)>
  loop.0_1 = loop_2;
  loop_6 = loop.0_1 + 1;
  __builtin_snprintf (&buf, 11, "%d", loop.0_1);
  if (loop_6 <= 9)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 5> :
  goto <bb 3>; [100.00%]
and ranger says [irange] int [-2147483647, 9]
Haven't checked if it just for -O0 doesn't look outside of the loop or what,
not looking outside of the loop would give [-2147483648, 9] IMHO though.
Anyway, in g it is asked about old_5 in:
  <bb 2> :
  loop_3 = 1;

  <bb 3> :
  # loop_1 = PHI <loop_3(2), loop_6(5)>
  old_5 = loop_1;
  loop_6 = loop_1 + 1;
  __builtin_snprintf (&buf, 11, "%d", old_5);
  if (loop_6 <= 9)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 5> :
  goto <bb 3>; [100.00%]
and returns [irange] int [1, 9] in that case.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bisection shows that first in
r12-5014-g6b8b959675a3e14cfdd2145bd62e4260eb193765
we started to warn on both f and g in #c5 at -O0 -Wall, and then
since r12-7870-g28c5df79300ab354cbc381aab200f7c2bd0331ad it only warns in f and
not in g anymore.

[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at gcc dot gnu.org