RFR(S): 8252407: Build failure with gcc-8+ and asan

[Kim Barrett]

> On Sep 1, 2020, at 5:46 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Sep 1, 2020, at 4:01 AM, Eric Liu <eric.c.liu at arm.com> wrote:
>> 
>> Hi all,
>> 
>> Please review this simple change to fix some compile warnings.
>> 
>> The newer gcc (gcc-8 or higher) would warn for calls to bounded string
>> manipulation functions such as 'strncpy' that may either truncate the
>> copied string or leave the destination unchanged.
>> 
>> This patch fixed stringop-truncation warnings reported by gcc, some of
>> them only appear when compiled with "--enable-asan".
>> 
>> [TESTS]
>> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
>> No new failure found.
>> 
>> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8252407
>> 
>> Thanks,
>> Eric
> 
> I really hate -Wstringop-truncation.  It's been a constant source of churn
> for us ever since it appeared.  The changes being made to getIndex and
> getFlags (NetworkInterface.c) are modifying lines that were changed very
> recently to deal with such warnings from gcc10.  I'm worried that these new
> changes will re-trigger warnings from gcc10 (though this change isn't a
> revert; the gcc10 warning was justifiable).  I think it should be okay, but
> there’s some risk here.
> 
> Changes look good, subject to that caveat.

Apparently I forgot about the discussion of the casted enum, so belay that.

>  I think these changes conform
> better to the documented description of the warning than did the recent
> NetworkInterface.c change mentioned above, so I’m hopeful that we’re not
> in a warning cycle here.  But it would be good to have someone test these
> changes against gcc10.x.