[Bug tree-optimization/103173] New: strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[Bug tree-optimization/103173] New: strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com]

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

            Bug ID: 103173
           Summary: strncpy output may be truncated copying 32 bytes from
                    a string of length 1439 (bogus)
                    [-Werror=stringop-truncation]
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrickdepinguin at gmail dot com
  Target Milestone: ---

gcc 11.2.0 gives a bogus warning of type 'stringop-truncation' on below reduced
test case.

.../arm-cortex_a53-linux-gnueabi-gcc -O2 -Wall -Werror -c /tmp/test.c -o
/tmp/foo.o                          
/tmp/test.c: In function 'func':
/tmp/test.c:22:5: error: 'strncpy' output may be truncated copying 32 bytes
from a string of length 1439 [-Werror=stringop-truncation]
   22 |     strncpy(dest, data[j].name, sizeof(dest));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors


-----------------

#include <string.h>

struct data_struct {
    char name[32];
    int bar;
};

void func()
{
    extern struct data_struct data[40];
    extern char dest[32];

    int j=0;
    strncpy(dest, data[j].name, sizeof(dest));
};

-----------------


Here 'dest' is correctly interpreted as an array of size 32, but 'data[j].name'
is interpreted as having size 1439 which is incorrect, as it should also have
size 32 (name member of struct data_struct).

Following factors influence the reported size 1439:
* if data_struct is given more or less additional members, like 'bar'
* if the array length of 'data' (40) is changed
* if the length of the 'name' array in data_struct is changed

If 'j' is replaced by 0 directly, as in:
    strncpy(dest, data[0].name, sizeof(dest));
the error disappears.


This problem did not occur on our previous toolchain with gcc 7.4.0 for the
same architecture, nor for x86_64 with gcc 7.5.0.

Info from gcc -v:

Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/11.2.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (crosstool-NG 1.24.0.487_10ac846)

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-11-10
           Keywords|                            |diagnostic
             Blocks|                            |88781

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed.  The warning here is the result of the limits of the representation
GCC uses for the source argument.  The warning sees the following IL:

  strncpy (&dest, &MEM <char[32]> [(void *)&data], 32);

and uses the size of data as the upper bound on the length of the string stored
in it.  That obviously doesn't correspond to the source code which is more
closely represented by this IL:

  j = 0;
  _1 = &data[j].name;
  strncpy (&dest, _1, 32);

But as the IL changes from the original representation above to the &MEM thing
to make it easier for optimizers to work with, it loses that important detail
and causes the false positive.

The "fix" is to either try to undo the IL change and reconstruct the original
(which is never going to be perfect) or to run the warnings on the IL before it
loses the important detail.  The latter will mean that the warning will not
benefit from some of the optimizing transformations that depend on the MEM
representation.  All solutions involve trade-offs between false positives and
false negatives.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
&MEM <char[32]> [(void *)&data] should have been folded to &data btw

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com]

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

--- Comment #3 from Thomas De Schampheleire <patrickdepinguin at gmail dot com> ---
While the original test program failed on gcc 11.2.0 but not on gcc 9.4.0, I
now encounter a very similar case that does fail on gcc 9.4.0:

------------------------------
#include <stdio.h>

#define MAX_NR_USERS 10

struct user_data {
  char user[32];
  char password[32];
  char application[32];
};

struct user_data users[MAX_NR_USERS];

void login_process()
{
    char tmp_user[33];

    for (int i = 0; i < MAX_NR_USERS; i++)
    {
        snprintf(tmp_user, sizeof(tmp_user), "%s", &(users[i].user[0]));
    }
}
------------------------------


arm-cortex_a53-linux-gnueabi-gcc /tmp/gcc-9-test.c -c -Wall -O2                 
/tmp/gcc-9-test.c: In function 'login_process':
/tmp/gcc-9-test.c:19:47: warning: '%s' directive output may be truncated
writing up to 959 bytes into a region of size 33 [-Wformat-truncation=]
   19 |         snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
      |                                               ^~
/tmp/gcc-9-test.c:19:9: note: 'snprintf' output between 1 and 960 bytes into a
destination of size 33
   19 |         snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Here, the claimed 960 bytes are the total size of 'users' (3 * 32 * 10), while
the copied 'user' field is only 33 byte and there should be no problem.
The error is now -Wformat-truncation instead of -Wstringop-truncation but
otherwise this looks to be the same underlying problem.

This compiler is:

Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/9.4.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-tm-clone-registry --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-libmpx
--with-gmp=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 9.4.0 (crosstool-NG 1.24.0.487_10ac846)

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com]

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

--- Comment #4 from Thomas De Schampheleire <patrickdepinguin at gmail dot com> ---
Note also that in the test program of comment #3, there is no problem if using
the 'password' or 'application' fields, rather than 'user', which is first in
the structure.

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[georgmueller at gmx dot net]

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

Georg Müller <georgmueller at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |georgmueller at gmx dot net

--- Comment #5 from Georg Müller <georgmueller at gmx dot net> ---
The problem in comment #3 is still valid vor gcc 13.1.1 (testes using
gcc-13.1.1-4.fc38.x86_64 on Fedora 38).

The warning disappears if I add a variable "int x" into the first place of
struct user_data.

The compiler seems to mix up the struct size and size of a member if they point
to the same memory address...