Re: RFR 8216417: cleanup of IPv6 scope-id handling

Good point Daniel. Thanks for the review. - Michael. On 10/06/2019, 19:48, Daniel Fuchs wrote: Hi Michael, AbstractPlainDatagramSocketImpl.java: in `send` maybe the packet should only be recreated if the address is different. best regards, -- daniel On 10/06/2019 15:18, Michael McMahon wro

Re: [teststabilization] RFR: 8225512: Replace wildcard address with loopback or local host in tests - part 15

Looks like a useful improvement for test stabilization Daniel. Looks good to me. Michael. On 10/06/2019, 15:14, Daniel Fuchs wrote: Hi, Please find below a fix for: 8225512: Replace wildcard address with loopback or local host in tests - part 15 https://bugs.openjdk.java.net/browse/JD

Re: RFR 8216417: cleanup of IPv6 scope-id handling

Thanks for the review Alan. I've made the changes suggested by you and Daniel and added a test to Scoping.java for checking the connected IP address. http://cr.openjdk.java.net/~michaelm/8216417/webrev.3/index.html - Michael On 10/06/2019, 16:49, Alan Bateman wrote: On 10/06/2019 15:18, Micha

Re: RFR 8216417: cleanup of IPv6 scope-id handling

On 11/06/2019 12:11, Michael McMahon wrote: Thanks for the review Alan. I've made the changes suggested by you and Daniel and added a test to Scoping.java for checking the connected IP address. http://cr.openjdk.java.net/~michaelm/8216417/webrev.3/index.html One suggestion for the AbstractPlainS

Re: RFR 8216417: cleanup of IPv6 scope-id handling

Michael, > On 11 Jun 2019, at 12:11, Michael McMahon > wrote: > > Thanks for the review Alan. > I've made the changes suggested by you and Daniel > and added a test to Scoping.java for checking the connected IP address. > > http://cr.openjdk.java.net/~michaelm/8216417/webrev.3/index.html Look

Re: RFR 8216417: cleanup of IPv6 scope-id handling

Hi Chris DatagramSocket has its own copies of the same fields and it stores the values supplied by the caller (rather than the scopified version), which are returned by getRemoteSocketAddress() and getInetAddress(). Michael. On 11/06/2019, 14:19, Chris Hegarty wrote: Michael, On 11 Jun 2019,

Re: RFR 8216417: cleanup of IPv6 scope-id handling

Michael, > On 11 Jun 2019, at 14:55, Michael McMahon > wrote: > > Hi Chris > > DatagramSocket has its own copies of the same fields and it stores > the values supplied by the caller (rather than the scopified version), > which are returned by getRemoteSocketAddress() and getInetAddress(). > A

Re: RFR 8216417: cleanup of IPv6 scope-id handling

Hi Alan I've made the suggested changes. I need to confirm with Pavel what the background was for the Linux kernel check. For now, it is still there in the test. Maybe, that could be removed as part of another change later, if that turns out to be possible. Updated webrev: http://cr.openjdk.

Re: RFR 8216417: cleanup of IPv6 scope-id handling

On 11/06/2019 18:14, Michael McMahon wrote: Hi Alan I've made the suggested changes. I need to confirm with Pavel what the background was for the Linux kernel check. For now, it is still there in the test. Maybe, that could be removed as part of another change later, if that turns out to be p

8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

https://bugs.openjdk.java.net/browse/JDK-8223813 http://cr.openjdk.java.net/~bpb/8223813/webrev.00/ FormatMessage() and FormatMessageW() occur in a number of locations: src/java.base/windows/

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Brian, Having the extraneous suffix consistently removed seems like a good thing. Though I'm not sure what the best form of the utility function is:  1) return the count of characters to remove  2) just truncate the buffer. There may be ways to force some of the errors that would lead to the

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Roger, Thanks for the $0.02. > On Jun 11, 2019, at 12:14 PM, Roger Riggs wrote: > > Having the extraneous suffix consistently removed seems like a good thing. > Though I'm not sure what the best form of the utility function is: > 1) return the count of characters to remove > 2) just trunca

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Brian! Inet4AddressImpl.c: 1) There is an extra space after FormatMessage, 2) It is preexisting. The code doesn't check if FormatMessage failed to allocate the buffer. It's not clear from the MSDN documentation, if the pointer to the buffer will be set to NULL upon the failure. If it does

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Hi Ivan, I updated the patch: http://cr.openjdk.java.net/~bpb/8223813/webrev.01/ Please see comments inline below. > On Jun 11, 2019, at 5:06 PM, Ivan Gerasimov wrote: > > Inet4AddressImpl.c: > > 1) There is an extra space after FormatMess

[PATCH] JDK-8217705 - HTTPClient wrong exception type when bad status line is received

Hello, Attached is a patch for the issue reported at https://bugs.openjdk.java.net/browse/JDK-8217705. In addition to catching the NumberFormatException that can arise while parsing (an invalid) status code in the status line, this change also checks that the status code is indeed a 3-digit integ

Re: 8223813: (aio) Iocp.getErrorMessage should drop trailing \r\n

Thanks Brian! The webrev looks fine to me. I think that *most likely* the check if (buf != NULL) will work as expected: buf will only be set to non-NULL value upon success. However, the documentation for the function FormatMessage states: """ If the function fails, the return value is zero.