On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
wrote:
> Hello, newbie here
>
> I picked JDK-8138732 to work on because it has a "starter" label and I
> believe I understand what to do.
>
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since` from
Hi Philippe,
On 8/09/2020 3:08 am, Philippe Marschall wrote:
Hello, newbie here
Welcome aboard!
I picked JDK-8138732 to work on because it has a "starter" label and I believe
I understand what to do.
- I tried to update the copyright year to 2020 in every file.
- I decided to change `@sinc
> 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
On Mon, 7 Sep 2020 18:57:11 GMT, Sean Coffey wrote:
>> Continuation of RFR thread from
>> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>>
>> CSR has been approved.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the l
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote:
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
This pull request has now been integrated.
Changeset: 7686e871
Author:Sean Coffey
URL: http
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
Sean Coffey has updated the pull request incrementally with one additional
commit since the last revision:
Copyright and test clean up
-
Ch
On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
wrote:
> Hello, newbie here
>
> I picked JDK-8138732 to work on because it has a "starter" label and I
> believe I understand what to do.
>
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since` from
Hello, newbie here
I picked JDK-8138732 to work on because it has a "starter" label and I believe
I understand what to do.
- I tried to update the copyright year to 2020 in every file.
- I decided to change `@since` from 9 to 16 since it is a new annotation name
in a new package.
- I tried to k
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote:
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
Marked as reviewed by weijun (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/56
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote:
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
I think this looks good over all Sean. In your SymLinkTest, I probably would
have the test delete th
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
Continuation of RFR thread from
http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
CSR has been approved.
-
Commit messages:
- JDK-8250968
Changes: https://git.openjdk.java.net/jdk/pull/56/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&ran
* 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
18 matches
Mail list logo
