RFR(S): 8252407: Build failure with gcc-8+ and asan
Kim Barrett
kim.barrett at oracle.com
Mon Sep 7 01:51:06 UTC 2020
> On Sep 6, 2020, at 7:35 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 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.
>
> 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.
I found a gcc10.2 devkit that I could take for a spin with Eric's
patches. I got -Wstringop-truncation warnings in NetworkInterface.c,
in getIndex and getFlags. Removing the immediately preceeding memset
removed those warnings. (Note that in these two cases the memset is
otherwise completely superfluous, both before and after Eric's changes.)
Strangely, there are other places in this file where a strncpy is
preceeded by a memcpy and there is no assignment of the last element
to NUL, but which no version of gcc seems to complain about. Examples
include getMacAddress, getMTU, enumIPv6Interfaces.
Oh, good grief! This file contains 3 identical copies of getMTU and
getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a
mess. If changing any of these for linux, probably similar changes
ought to be applied to the other copies to keep things in sync.
After removing the superfluous memsets from getIndex and getFlags, my
test build with gcc10.2 completed successfully with Eric's patches.
More information about the core-libs-dev
mailing list