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

2020-09-01 Thread Kim Barrett
> On Sep 1, 2020, at 4:01 AM, Eric Liu 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 leav

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

2020-09-01 Thread Kim Barrett
> On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote: > >> On Sep 1, 2020, at 4:01 AM, Eric Liu 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

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

2020-09-02 Thread Kim Barrett
> On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote: > > * Magnus Ihse Bursie: > >> 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,

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

2020-09-02 Thread Kim Barrett
> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie > wrote: > > On 2020-09-01 11:46, Kim Barrett wrote: >> 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 >>

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

2020-09-07 Thread Kim Barrett
> On Sep 6, 2020, at 1:03 PM, Florian Weimer wrote: > There is no reason to use strncpy. At least on Linux, the struct field > needs to be null-terminated, and you need to compute the length for the > length check. So you might as well use memcpy with the length plus one > (to copy the null term

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

2020-09-07 Thread Kim Barrett
> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: > > * Daniel Fuchs: > >> Hi, >> >> On 02/09/2020 08:19, Florian Weimer wrote: >>> At least one of the bugs was in theory user-visible: the network >>> interface code would return data for an interface that does not actually >>> exist on the sy

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

2020-09-07 Thread Kim Barrett
> On Sep 1, 2020, at 9:59 AM, Eric Liu wrote: > I just tested this patch by GCC (10.1.0) and it would really re-trigger those > warnings :( > I have not noticed the history before, but it's really hard to imagine that > GCC would > have different behaviors. Can you be (very) specific about thi

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

2020-09-07 Thread Kim Barrett
> On Sep 6, 2020, at 9:51 PM, Kim Barrett wrote: > 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 appli

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

2020-09-07 Thread Kim Barrett
> On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/hotspot/share/compiler/compileBroker.hpp > 64 PRAGMA_DIAG_PUSH > 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED > 66 // This code can incorrectly cause a "stringop-truncation" warning > with gcc > 67

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

2020-09-07 Thread Kim Barrett
> On Sep 6, 2020, at 7:35 AM, Kim Barrett 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

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

2020-09-08 Thread Kim Barrett
> On Sep 7, 2020, at 10:56 AM, Eric Liu 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* stran

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

2020-09-08 Thread Kim Barrett
> On Sep 7, 2020, at 5:55 AM, Florian Weimer wrote: > > * Kim Barrett: > >> And strlen is not even necessarily the best solution, as it likely >> introduces an additional otherwise unnecessary string traversal. For >> example, getFlags could be changed t

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

2020-09-24 Thread Kim Barrett
> On Sep 23, 2020, at 2:10 AM, Eric Liu wrote: > > Hi Kim, > > Sorry for the delay. > > This patch removes a redundant string copy in NetworkInterface.c to avoid > string-truncation > warning. Other warnings we talked before, which are unable to completely fix > in different version > of g

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

2020-09-29 Thread Kim Barrett
> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: > > Hi, > > Thanks for looking at this. > > For gcc-10, it's hard to make 'strncpy' all right with asan enabled > (approaches we talked previous don't work). > I'm trying to find a better way to avoid using compile pragma. I suppose it > would

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

2020-09-29 Thread Kim Barrett
> On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: > >> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >> >> Hi, >> >> Thanks for looking at this. >> >> For gcc-10, it's hard to make 'strncpy' all right with asan enabled >>

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

2020-09-30 Thread Kim Barrett
> On Sep 30, 2020, at 3:30 AM, Eric Liu wrote: > > Hi Kim, > > Thanks for your review. > I tried to solve the problem with your suggestion, and have just one question. > >> On 29 September 2020 18:51 PM, Kim Barrett wrote: >> With gcc10.2, and using the --ena

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

2020-09-30 Thread Kim Barrett
> On Sep 30, 2020, at 7:09 AM, Magnus Ihse Bursie > wrote: > > > > On 2020-09-29 13:17, Kim Barrett wrote: >> Another option might be to solve >> https://bugs.openjdk.java.net/browse/JDK-8232187 >> > Will that really help? If a os::strncpy_s me