> On Oct 10, 2019, at 3:03 AM, David Holmes <david.hol...@oracle.com> wrote: > > On 10/10/2019 4:50 pm, Chris Plummer wrote: >> From JBS: >> >> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >> warning: 'char* strncpy(char*, const char*, size_t)' output truncated >> before terminating nul copying as many bytes from a string as its length >> [-Wstringop-truncation] >> 154 | strncpy(buf, str, len); >> | ~~~~~~~^~~~~~~~~~~~~~~ >> I assume this means that in all cases the "len" value is seen to be derived >> from strlen, and therefore strncpy is always copying one byte short of \0, >> and this is most likely not what the user wants. I seem to > > Yes but we then explicitly set the NULL at buf[len] which is the > expected/required pattern for this. > >> recall another recent similar fix that was done by switching to using memcpy >> instead. >> Here's a discussion of interest, also suggesting memcpy: >> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >> > > Seems to me that strncpy and memcpy are semantically equivalent here so all > this does is avoid gcc's over zealous warnings. I'm inclined to use the: > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wstringop-truncation" > > solution. > > YMMV.
We've run into and discussed problems with -Wstringop-truncation before. (See discussions of JDK-8214777 and JDK-8223186.) This is a relatively recent warning option (introduced in gcc8, and included in -Wall), and seems to have a considerable bug tail: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 A metabug for -Wstringop-truncation, currently with 16 open and 10 resolved associated bugs. I'm not a fan of replacing correct and idiomatic uses of strncpy with strcpy or memcpy. I've suggested in the past that we should turn off this warning while it is so buggy.
