error compiling with gcc 15.2.0 on mingw

[roboticarm2000]

I get the following error when trying to compile on mingw with gcc 15.2.0

cc -I. -Wall -O2 -pedantic -Werror -Wshadow -std=c99 -DYY_NO_INPUT -Wformat-truncation=1   -c -o cobra_prim.o cobra_prim.c
cobra_prim.c: In function 'dogrep':
cobra_prim.c:151:67: error: '%s' directive output may be truncated writing up to 2030 bytes into a region of size between 0 and 2030 [-Werror=format-truncation=]
  151 |                 snprintf(cmd, sizeof(cmd), "grep -q -n -e  \"%s\" %s",
      |                                                                   ^~
cobra_prim.c:151:17: note: 'snprintf' output between 19 and 4079 bytes into a destination of size 2048
  151 |                 snprintf(cmd, sizeof(cmd), "grep -q -n -e  \"%s\" %s",
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  152 |                         s, f->s);
      |                         ~~~~~~~~
cc1.exe: all warnings being treated as errors

[nimble-code]

I'll look into it

[nimble-code]

the warning is incorrect, given the if statement that just precedes the call to snprintf (which returns if the maximum size would be exceeded). still, that does leave the problem that gcc 15.2.0 flags it -- I'll have to think about how to handle this one.

[roboticarm2000]

I noticed the if statement guarding the call. Interestingly, it only triggers the error when using -O2 and -O3 but not when using -O1, -g, -Os. Perhaps, the compiler is truly finding and edge case?

[roboticarm2000]

The gcc manual says:
-Wformat-truncation-Wformat-truncation=level

Warn about calls to formatted input/output functions such as snprintf and
vsnprintf that might result in output truncation. When the exact number
of bytes written by a format directive cannot be determined at compile-time
it is estimated based on heuristics that depend on the level argument and
on optimization. While enabling optimization will in most cases improve the
accuracy of the warning, it may also result in false positives. Except as noted
otherwise, the option uses the same logic-Wformat-overflow.

-Wformat-truncation-Wformat-truncation=1
Level 1 of-Wformat-truncation enabled by-Wformat employs
a conservative approach that warns only about calls to bounded
functions whose return value is unused and that will most likely
result in output truncation.

It seems it'll always warn because it identified a potential scenario for truncation.
Increasing the size of cmd, doesn't help because the compiler can always find a larger input
that will cause truncation.

Googling on the warning suggested the use of dynamic memory to overcome the truncation issue.
It'll probably slow down the program :/

#include <stdio.h>
#include <stdlib.h>

int main() {
char *buffer;
int required_size = snprintf(NULL, 0, "Hello!") + 1; // Calculate required size
buffer = malloc(required_size);

if (buffer) {
snprintf(buffer, required_size, "Hello!");
printf("Buffer: %s\n", buffer);
free(buffer);
}
return 0;
}

[nimble-code]

I can't test it with the version of gcc that you're using, but I've a feeling that the warning would still pop up, in the assignment to required_size this time. isn't that the case?

[roboticarm2000]

The warning is not issued.

     for (n = 0; n < NHASH; n++)
        for (f = files[n]; f; f = f->nxt)
        {
          required_size = snprintf(NULL,0, "grep -q -n -e  \"%s\" %s",
                                   s, f->s)+1;
          cmd = malloc(required_size);
          if (cmd) {
            snprintf(cmd, required_size, "grep -q -n -e  \"%s\" %s",
                     s, f->s);
            if (system(cmd) == 0)       // dogrep
              { printf("%s:\n", f->s);
              }
            cmd[5] = cmd[6] = ' ';
            if (system(cmd) < 0)        // dogrep
              { printf("cmd '%s' failed\n", cmd);
              }
            free(cmd);
          }
        }

As described in the documentation, the compiler is really using a heuristic of noting that the first version of sprintf is called and disables the warning. The compiler is not checking that the sizes make sense (because they can't be determined at compiled time). The warning does not trigger even if I call the second version of snprintf with required_size/2 which will definitely truncate.

I tried to compile the original dogrep function using https://godbolt.org/ with gcc 15.2.0 and it didn't trigger the warning. I wonder if this is a mingw gcc issue :/

[nimble-code]

I'll update the code.
Thanks for checking this so carefully!
-g