> 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 method is added to hotspot, how
> should NetworkI
On 2020-09-29 13:17, Kim Barrett wrote:
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 (approaches
we talked previous don't work).
I'm tryi
> 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 --enable-asan configure option, we get a
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:
> I don't think using memory functions in place of string functions for string
> manipulation is really an improvement.
Yes, the ori
> 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
>> (approaches we talked previous don't work).
>> I'm trying to find a
> 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
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 be better to use 'memcpy'
to replace 'strncpy'.
Thanks,
Eric
On 24/09/2020 09:59, Kim Barrett wrote:
If possible, my preference would be to avoid the pragma cruft and write the
code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't
warn with or without asan. I've kind of lost track in the discussion of all
the variants whether that's
> 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
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 gcc, I have to use pragma to suppress them as a workaround.
This pat
Hi Kim,
> Kim Barrett on Sent: 08 September 2020 20:28
>> 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
> 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 to reject an overly long ifname,
>> without
> 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
> 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;
>
> (in getIndex)
>
> S
> 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 strncpy(_current_method, method, (size_
> 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
> 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 applied to the other
> 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
> 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
Hi Kim:
Thanks for the discussion, this makes more sense to me now.
> Kim Barrett on 06 September 2020 19:35 wrote:
>
> Can you be (very) specific about this. Do all of these changes cause gcc10
> to warn? Or
> do only some of them. If only some, specifically which ones? I have a
> conjec
* 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 to reject an overly long ifname,
> without using strlen, thusly:
>
> strncpy(if2.ifr_name, ifname, siz
* 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 act
* 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 system.
>
> WRT NetworkInterface.c, I might support using `strnlen` t
> 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
>> getFlags (NetworkInterface.c) are modif
> 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,
On 2020-09-02 09:50, Kim Barrett wrote:
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
getFlags (
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 system.
WRT NetworkInterface.c, I might support using `strnlen` to check
the length before hand,
* 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,
> and that we provide sane semantics (which isn't really the c
On 2020-09-01 11:46, 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 bounded string
manipulation functions such as 'strncpy' that may either truncate t
> 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 bounded string
>> manipulation functions such as '
> 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
Hi Daniel, Kim,
Thanks for your review.
> Kim Barrett on Tue Sep 1 09:46:26 UTC 2020
>
> 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
Hi Eric, Kim,
On 01/09/2020 10:46, Kim Barrett wrote:
he 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 thi
Hi Eric,
The changes to NetworkInterface.c look good to me.
best regards,
-- daniel
On 01/09/2020 09:01, 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
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-truncati
35 matches
Mail list logo