Hi Kim,
> Kim Barrett <kim.barr...@oracle.com> on Sent: 08 September 2020 20:28 >> On Sep 7, 2020, at 10:56 AM, Eric Liu <eric.c....@arm.com> wrote: >> I have tested 4 cases for those warnings: >> a) Without my patch, without asan, gcc-8 and gcc-10 are OK. >> b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. >> c) With my patch, without asan, gcc-8 and gcc-10 are OK. > That’s *very* strange, since I get warnings in NetworkInterface getIndex and > getFlags > with gcc10.2 + your patch. Sorry for the mistake, gcc-10 exactly warn about my patch. >> d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. >> >> Those warnings can be reported by both gcc-8 and gcc-10 only when asan >> enabled. Without >> asan, no warning would be found even through some of them doesn't align with >> the documentation. >>> src/java.base/unix/native/libnet/NetworkInterface.c >>> 1298 memset((char *)&if2, 0, sizeof(if2)); >>> 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >>> 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >>> >>> (in getIndex) >>> >>> So gcc8 does not warn about this, but gcc10 does? That would be a >>> regression in gcc10 (and should be reported as such), because the >>> documentation for -Wstringop-truncate is clear that the above is the >>> proper idiom for avoiding the warning. >> >> Yse, I followed the documentation and gcc-8 does not warn about this, but >> gcc-10 does (both with asan enabled). >> >>> Regardless, the memset on 1298 is useless. The code from before >>> JDK-8250863 was the memset then the strncpy with >>> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >>> would have zeroed the last element. >>> >>> The change for JDK-8250863 did not follow the documented idiom though. >>> >>> It would be interesting to find out if removal of the memset changes >>> anything. It's barely conceivable that it's confusing the heuristics >>> used to decide whether -Wstringop-truncation should trigger. For >>> example, the compiler might decide that the subsequent assignment of >>> the last element is unnecessary because of the memset and optimize the >>> assignment away, removing the idiomatic warning suppression. >>> >>> If gcc10 still warns about the above after removing the memset then I >>> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >>> >>> Similarly for the strncpy in getFlags: >>> 1362 memset((char *)&if2, 0, sizeof(if2)); >>> 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >>> 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and >> gcc-9 also. > I’m confused. Above you said that with your patch + asan gcc-8 did not warn. > Maybe what you are saying is that *just* removing the memset, and not applying > your patch, for this case with asan warns with all of gcc-8,9,10? Sorry for my bad expression. Actually removing memset could not make things better. My patch + asan would annoy gcc-10, removing memset changed nothing. For gcc-8 and gcc-9 part, without my patch they would warn about with asan, and removing memset can not fix them as well. Thanks, Eric