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

[Magnus Ihse Bursie]

On 2020-09-01 11:46, Kim Barrett 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.
Maybe we should have a common library for all native code where we 
supply our own string operation functions? It will then be much easier 
to make sure the implementation passes different compiler versions, and 
that we provide sane semantics (which isn't really the  case with the 
original C library functions; hence all this warning churning).

There have been other problem areas before, where a common library 
(static or dynamic) would have helped. Perhaps it's time to go ahead and 
create one...

/Magnus
>
> Changes look good, subject to that caveat.  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.
>
>