Dear List
The latest update to my epanet2toolkit package bounced from CRAN due to
some warnings about string truncation in C code from gcc.
Found the following significant warnings:
input2.c:863:5: warning: ?__builtin_strncpy? output may be truncated
copying 225 bytes from a string of length 255 [-Wstringop-truncation]
input2.c:302:15: warning: ?__builtin_strncpy? output may be truncated
copying 78 bytes from a string of length 1024 [-Wstringop-truncation]
report.c:795:9: warning: ?__builtin_strncpy? output may be truncated
copying 967 bytes from a string of length 1024 [-Wstringop-truncation]
The package wraps a simulation engine that parses inputs from and
writes results to text files. Where the truncation warnings appear, I
am truncating on purpose using `strncpy` to avoid overflows later. I
believe this works fine from an application point of view but the
warnings remain.
Any suggestions on how to carry out a truncation so that gcc won't
complain?
Thanks in advance,
Brad
PS - CRAN check info is here
https://win-builder.r-project.org/incoming_pretest/epanet2toolkit_1.0.6_20241209_221743/specialChecks/
PPS the latest CRAN submission is from this branch
https://github.com/bradleyjeck/epanet2toolkit/tree/lto-crash
[R-pkg-devel] truncating strings on purpose
5 messages · Brad Eck, Ivan Krylov, Iris Simmons
? Wed, 11 Dec 2024 12:12:11 +0000 Brad Eck <bradleyjeck at gmail.com> ?????:
Found the following significant warnings:
input2.c:863:5: warning: ?__builtin_strncpy? output may be
truncated copying 225 bytes from a string of length 255
[-Wstringop-truncation]
Where the truncation warnings appear, I am truncating on purpose using `strncpy` to avoid overflows later. I believe this works fine from an application point of view but the warnings remain.
GCC documentation suggests setting the length argument to _one less_ than sizeof destination buffer in addition to terminating the string: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wstringop-truncation strncpy(trunc_s1, s1, sizeof trunc_s1 - 1); trunc_s1[sizeof trunc_s1 - 1] = '\0';
Best regards, Ivan
You could use memcpy instead. That gets rids of the type checking though.
You could also define something like char * my_strncpy ( char *
destination, const char * source, size_t num ) { return (char *)
memcpy(destination, source, num) } to keep the type checking.
On Wed, Dec 11, 2024, 07:12 Brad Eck <bradleyjeck at gmail.com> wrote:
Dear List
The latest update to my epanet2toolkit package bounced from CRAN due to
some warnings about string truncation in C code from gcc.
Found the following significant warnings:
input2.c:863:5: warning: ?__builtin_strncpy? output may be truncated
copying 225 bytes from a string of length 255 [-Wstringop-truncation]
input2.c:302:15: warning: ?__builtin_strncpy? output may be truncated
copying 78 bytes from a string of length 1024 [-Wstringop-truncation]
report.c:795:9: warning: ?__builtin_strncpy? output may be truncated
copying 967 bytes from a string of length 1024 [-Wstringop-truncation]
The package wraps a simulation engine that parses inputs from and
writes results to text files. Where the truncation warnings appear, I
am truncating on purpose using `strncpy` to avoid overflows later. I
believe this works fine from an application point of view but the
warnings remain.
Any suggestions on how to carry out a truncation so that gcc won't
complain?
Thanks in advance,
Brad
PS - CRAN check info is here
https://win-builder.r-project.org/incoming_pretest/epanet2toolkit_1.0.6_20241209_221743/specialChecks/
PPS the latest CRAN submission is from this branch
https://github.com/bradleyjeck/epanet2toolkit/tree/lto-crash
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
2 days later
Hi Ivan, List,
Thanks for the suggestion, and for the pointer on duplicating the error.
The good news is that I am able to trigger the warning locally now. The bad
news is that following the gcc docs on avoid the warning did not seem to
work:
gcc -std=gnu99 -fsanitize=undefined -fno-omit-frame-pointer -std=gnu11
-I"/usr/local/lib/R/include" -DNDEBUG -I/usr/local/include
-fsanitize=address
-O2 -Wstringop-truncation -fPIC -g -O2 -c input2.c -o input2.o
input2.c: In function ?inperrmsg?:
input2.c:863:5: warning: ?strncpy? output may be truncated copying 225
bytes from a string of length 255 [-Wstringop-truncation]
863 | strncpy(trunc_tok, tok, sizeof trunc_tok - 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I could also try memcpy, but i don't so much like the idea of going away
from string functions for string handling.
Other suggestions are also welcome.
Brad
On Wed, Dec 11, 2024 at 1:29?PM Ivan Krylov <ikrylov at disroot.org> wrote:
? Wed, 11 Dec 2024 12:12:11 +0000 Brad Eck <bradleyjeck at gmail.com> ?????:
Found the following significant warnings:
input2.c:863:5: warning: ?__builtin_strncpy? output may be
truncated copying 225 bytes from a string of length 255
[-Wstringop-truncation]
Where the truncation warnings appear, I am truncating on purpose using `strncpy` to avoid overflows later. I believe this works fine from an application point of view but the warnings remain.
GCC documentation suggests setting the length argument to _one less_ than sizeof destination buffer in addition to terminating the string: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wstringop-truncation strncpy(trunc_s1, s1, sizeof trunc_s1 - 1); trunc_s1[sizeof trunc_s1 - 1] = '\0'; -- Best regards, Ivan
2 days later
Dear Brad, Kurt, ? Fri, 13 Dec 2024 18:08:27 +0000 Brad Eck <bradleyjeck at gmail.com> ?????:
The bad news is that following the gcc docs on avoid the warning did not seem to work:
I have asked on Libera.Chat's #gcc and was told that the "middle-end" warnings [1] (which include -Wstringop-truncation) should not count as failures when Address Sanitizer is enabled. (Many thanks to Sam James and Arsen Arsenovi? for the triage!) While we don't literally use -Werror, de-facto the result is the same: the package doesn't pass the check if the warning is emitted. The reason for that is that the "middle-end" warnings require optimisation to avoid false positives in the unreachable code paths, and sanitizers change optimisation too much for the warnings to remain reliable [2]. A similar false positive has been reported before [3]. Can we use -Wno-stringop-truncation during incoming checks with ASan?