On 2020-09-01 11:46, Kim Barrett wrote:
On Sep 1, 2020, at 4:01 AM, Eric Liu <eric.c....@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.
