ebrev/
Sincerely yours,
Ivan Gerasimov
erage
machine, with the extra iterations?
-Chris.
On 09/10/2013 09:24, Ivan Gerasimov wrote:
Hello all!
The MemLeakTest had been added with the fix for 8022584.
Since that, the test was reported to fail intermittently, even though
the leak was eliminated.
I couldn't ever reproduce the failure e
On 10.10.2013 15:52, Ivan Gerasimov wrote:
Hi Chris!
I've run the test on JPRT and it took 84, 99 and 146 seconds on three
different machines.
When I run it locally in the virtualbox, it takes approximately 300
seconds.
Please note that even though the number of iterations was increas
ive memory usage
turns out to be unreliable.
At first it seemed promising.
Sincerely yours,
Ivan
-Chris.
On 11/10/2013 20:24, Ivan Gerasimov wrote:
On 10.10.2013 15:52, Ivan Gerasimov wrote:
Hi Chris!
I've run the test on JPRT and it took 84, 99 and 146 seconds on three
different m
Thank you Chris!
Here's the exported patch with the test removal:
http://cr.openjdk.java.net/~igerasim/2commit/8023390-jdk8-remove-MemLeakTest.patch
Sincerely yours,
Ivan Gerasimov
On 15.10.2013 16:54, Chris Hegarty wrote:
On 10/15/2013 11:19 AM, Ivan Gerasimov wrote:
On 14.10.2013
Hello Eric
Would you please also correct the comment on the line above your change:
s/seudo/pseudo/
The typo is in all three files.
Sincerely yours,
Ivan
On 27.02.2014 12:18, Eric Wang wrote:
On 2014/2/25 16:59, Alan Bateman wrote:
On 25/02/2014 08:49, Eric Wang wrote:
Hi Everyone,
I'm wo
Hello!
The strtok() function is used in
./windows/native/sun/net/spi/DefaultProxySelector.c.
This function is not thread safe, so it may potentially cause a problem.
The failure in this particular place would be very unlikely, because
this code should be executed only once during initializati
Hi Christos!
On 03.03.2014 20:52, chris...@zoulas.com wrote:
On Mar 3, 8:32pm, ivan.gerasi...@oracle.com (Ivan Gerasimov) wrote:
-- Subject: RFR: [8036088] - Thread-unsafe strtok() is used to parse the list
| Hello!
|
| The strtok() function is used in
| ./windows/native/sun/net/spi
+0400
From: Ivan Gerasimov
Subject: Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse
the list of overrides
To: Christos Zoulas ,OpenJDK Network Dev list
Message-ID: <5314b55b.9070...@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
n
On 04.03.2014 14:28, Chris Hegarty wrote:
On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote:
Yes, you're right.
strtok() is thread-safe in Windows unlike its Unix counterpart.
Thus using strtok_s() only adds some boundary checking in this case.
Ivan,
Are you now withdrawing this reque
Thank you Chris!
On 04.03.2014 16:43, Chris Hegarty wrote:
On 4 Mar 2014, at 11:52, Ivan Gerasimov wrote:
VS compiler issues this warning on strtok() usage:
: warning C4996: 'strtok': This function or variable may be unsafe. Consider
using strtok_s instead. To disable deprec
Hi Chris!
Would it be good to include a couple more typo fixes in this change?
diff --git a/src/share/classes/java/net/DatagramSocket.java
b/src/share/classes/java/net/DatagramSocket.java
--- a/src/share/classes/java/net/DatagramSocket.java
+++ b/src/share/classes/java/net/DatagramSocket.java
Wouldn't it be a little bit more efficient to replace a string
concatenation with yet another StringBuilder operation?
src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
631 StringBuilder sb = new StringBuilder();
...
636 Utils.log.fine(" meta-c
src/share/classes/sun/misc/UUDecoder.java
126 StringBuilder x = new StringBuilder();
Is only filled, but doesn't seem to be used anyhow.
Maybe just delete it?
Sincerely yours,
Ivan
On 12.05.2014 14:03, Paul Sandoz wrote:
Hi,
This is a request for review of Otavio's patch replacing
Hello!
In the implementation of TwoStack sockets on Windows there's is a
possibility of trying to close the sockets twice in the case of a failure.
TwoStack implementation isn't the default one, but it still can be used
with jdk7u/8u on old platforms.
Would you please help review the fix?
BU
Hello!
Here is a proposal for the first step in cleaning up the TwoStacks
socket implementation.
It is proposed to drom IPv6 support in the implementation of
TwoStacksPlainSocketImpl class (so formally, it's no more Two Stacks).
Therefore, this class will only be used when the user explicitly
Thanks Michael!
On 23.09.2014 13:41, Michael McMahon wrote:
Hi Ivan,
Did you look at the possibility of removing the TwoStacks class
altogether?
For Solaris/Linux etc. ipv4 only and ipv6/v4 are all handled in the
same impl class
with just a switch at socket creation time, selecting AF_INET or
Thank you Michael!
Okay. I see the "part 1" in the subject line now, but maybe the bug
should be updated
to define the scope of the change and we should file a separate bug
report then.
I created the subtask to track this part (the subject of the thread is
changed accordingly):
https://bugs
Hello!
This is a javadoc bug.
In the code sample a redundant argument to a constructor of URI is passed.
Probably a copy-paste error.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059450
WEBREV: http://cr.openjdk.java.net/~igerasim/8059450/0/webrev/
Sincerely yours,
Ivan
Thanks Chris!
On 01.10.2014 20:49, Chris Hegarty wrote:
On 1 Oct 2014, at 01:48, Ivan Gerasimov wrote:
Hello!
This is a javadoc bug.
In the code sample a redundant argument to a constructor of URI is passed.
Probably a copy-paste error.
BUGURL: https://bugs.openjdk.java.net/browse/JDK
Hi Volker!
I'm not a Reviewer, but have a couple of minor comments.
In the C source files you changed the indentation to two spaces.
It looks inconsistent with other JDK sources.
I know that in hotspot they use two space indentation, but it's a
different set of sources.
Inet4AddressImpl.c:
1
On 27.10.2014 21:45, Volker Simonis wrote:
On Fri, Oct 24, 2014 at 7:07 PM, Ivan Gerasimov
wrote:
Hi Volker!
I'm not a Reviewer, but have a couple of minor comments.
In the C source files you changed the indentation to two spaces.
It looks inconsistent with other JDK sources.
I know th
Hi Chris!
I think it's better to pass the last argument to SetHandleInformation as
0 rather than FALSE.
This argument is DWORD flag, which is a bit subset of the second argument.
Sincerely yours,
Ivan
On 28.01.2015 23:01, Chris Hegarty wrote:
Reviving an old code review [1], after further in
Hello!
There has been a deadlock in jdk-net code noticed on Windows.
In the bug description there's a stack snippet showing that one of the
deadlocked threads stuck in the native initialization code of
DualStackPlainDatagramSocketImpl and the other -- in initializing of
TwoStacksPlainDatagram
Can someone help review this fix please?
Comments/suggestions are welcome!
Sincerely yours,
Ivan
On 06.02.2015 20:48, Ivan Gerasimov wrote:
Hello!
There has been a deadlock in jdk-net code noticed on Windows.
In the bug description there's a stack snippet showing that one of the
deadl
This looks good.
In general, it might be more appropriate to review this on
net-dev@openjdk.java.net alias.
Sincerely yours,
Ivan
On 02.09.2015 16:22, Vyom Tewari wrote:
Hi everyone,
Can you please review my changes for below bug.
Bug:
JDK-8080486 : JNI exception pending in
jdk/src/
66
WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/
Sincerely yours,
Ivan
On 17.02.2015 9:54, Ivan Gerasimov wrote:
Can someone help review this fix please?
Comments/suggestions are welcome!
Sincerely yours,
Ivan
On 06.02.2015 20:48, Ivan Gerasimov wrote:
Hello!
There has been a
Hi!
The close() function isn't really restartable.
So, I think, it's more correct to replace
RESTARTABLE(close(s), res);
with
res = close(s);
Sincerely yours,
Ivan
On 07.09.2015 12:26, Vyom Tewari wrote:
Hi everyone,
Can you please review my changes for below bug.
Bug:
JDK-80804
Thanks!
It looks good to me now.
Sincerely yours,
Ivan
On 07.09.2015 16:08, Vyom Tewari wrote:
Hi All,
Please find the latest diff, which contains the latest fix.
http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
Thanks,
Vyom
On 9/7/2015 3:48 PM, Alan Bateman wrote:
On 07/09/201
Thank you Chris for the review!
Sincerely yours,
Ivan
On 07.09.2015 17:39, Chris Hegarty wrote:
This looks like a nice cleanup, and fix. Thanks Ivan.
-Chris.
On 05/09/15 15:25, Ivan Gerasimov wrote:
Hi everyone!
The fix didn't bring enough attention back in February for some reaso
Hello!
I'd like to backport this recent fix from jdk9 to jdk8u-dev.
The fix applies *almost* cleanly after unshuffling.
The only manual editing I had to do was creating
Java_java_net_DualStackPlainDatagramSocketImpl_initIDs() function in
DualStackPlainDatagramSocketImpl.c, which didn't exist in
Hi Vyom!
The change looks fine, thanks.
You've used strerr() to extract the error string, so it may be good to
coordinate your patch with the fix for JDK-8133249.
Robert (CCed) is working on it at the moment.
Sincerely yours,
Ivan
On 16.09.2015 12:08, Vyom Tewari wrote:
Hi All,
Please revi
Hello!
A few failures of the recently added regtest were observed.
The failures seem to be due to slow machines.
The suggested fix is to
1) increase the timeout,
2) take into account the timeout factor from the jtreg's settings,
3) measure the time of individual cycle of the loop, and give up, i
Thank you Chris for review and proofreading! :-)
Sincerely yours,
Ivan
On 21.10.2015 15:21, Chris Hegarty wrote:
Looks fine Ivan,
Just a typo on:
48 Utils.adjustTimeout(CHILDREN_COUNT * CHILD_TIMEOT * 2);
-Chris.
On 21/10/15 11:06, Ivan Gerasimov wrote:
Hello!
A few failures of the
Hi Ramanand!
Your fix looks good to me.
I'm forwarding your request to net-dev@openjdk.java.net which is
probably more appropriate to review this fix.
It would be good, if net-dev people can confirm they're Okay with the fix.
Sincerely yours,
Ivan
On 10.02.2016 10:08, Ramanand Patil wrote:
As this has to be re-reviewed, sending the request to net-dev list as well.
On 27.05.2016 16:46, Ivan Gerasimov wrote:
Hello!
I'd like to backport the fix to jdk8u-dev.
The fix had to be slightly adjusted due to the different way the error
messages are retrieved in jdk8.
Here&
Could someone please help review this simple backport?
Thanks in advance,
Ivan
On 29.05.2016 21:08, Ivan Gerasimov wrote:
As this has to be re-reviewed, sending the request to net-dev list as
well.
On 27.05.2016 16:46, Ivan Gerasimov wrote:
Hello!
I'd like to backport the fix to
]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365915(v=vs.85).aspx
--
With kind regards,
Ivan Gerasimov
increase number of retries.
With kind regards,
Ivan
On 9/19/17 10:50 AM, Ivan Gerasimov wrote:
Hello!
When retrieving information about network interfaces on Windows we
make up to 2 attempts to call GetAdaptersAddresses().
It was reported that in very rare cases it may not be sufficient, and
(I would probably have coded the retry count counting down to zero but
its the same effect).
Regards, Roger
On 9/25/2017 1:03 PM, Ivan Gerasimov wrote:
Ping.
Please review the proposed change at your convenience.
The fix will greatly reduce the possibility of a need to reallocate
the buffer
} system property.
+ * the setting of the {@code jdk.net.hosts.file} system property.
*
* The default NameService is the PlatformNameService, which
typically
* delegates name and address resolution calls to the underlying
Would you approve the fix?
--
With kind regards,
Ivan
a.net/~igerasim/8058965/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
asier to review.)
The patched JDK builds fine and all the regression tests pass Okay.
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Best regards
Christoph
-Original Message-
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
Ivan Gerasimov
Sent: Freitag, 2. März 2018 05:43
To: Chris Hegarty ; net-dev@openjdk.java.net
Subject: RFR [11] 8198358 : Align organization of DualStackPlainSocketImpl
h all the changes above is available here:
http://cr.openjdk.java.net/~igerasim/8198358/01/webrev/
Thanks in advance!
Ivan
On 3/1/18 8:43 PM, Ivan Gerasimov wrote:
Hello!
I'd like to do the next step toward removing the TwoStacks socket
implementation on Windows.
It would be aligni
be easier to apply.
That was the primary reason why I choose TwoStacks as the basis and
aligned DualStack with it.
It can surely be done the opposite way, though I want to make sure it is
the preferable way to go.
With kind regards,
Ivan
-Chris.
On 06/03/18 20:31, Ivan Gerasimov wrote
DK-8058965
--
With kind regards,
Ivan Gerasimov
Access.
-Chris.
On 06/03/18 20:31, Ivan Gerasimov wrote:
In order to make is easier to review the fix, I made the webrev.ksh
to generate a series of incremental webrevs from the mq patch stack.
Here's the list of the incremental changes with a brief comments:
WEBREV-000: http://cr.openjd
Hi Chris!
On 3/23/18 11:48 AM, Chris Hegarty wrote:
Ivan,
On 23/03/18 18:38, Ivan Gerasimov wrote:
Hi Chris!
I was about to submit a patch for 8198358 that heavily modifies
TwoStacksPlainSocketImpl to make it aligned with
DualStackPlainSocketImpl.
That patch will also remove this
t here, before returning -1.
I checked the other places, where family is checked to be AF_INET and
can confirm there's no other places where a socket gets closed.
With kind regards,
Ivan
--
With kind regards,
Ivan Gerasimov
Hello everyone!
A few modifications were done to the patch.
Below is the list of updated parts of the patch with comments about what
has changed, comparing to the previous version of the patch.
The patched JDK builds fine and all the tests pass well.
WEBREV-000: http://cr.openjdk.java.net/~ig
On 3/25/18 12:11 PM, Alan Bateman wrote:
On 25/03/2018 19:13, Ivan Gerasimov wrote:
:
In the code above, newfd was obtained from a call to accept() a few
lines before this check.
So, the Java code has no way of being aware of this socket, and it
will never be closed unless we do it right
od to push now?
Please let me know, if you'd like me to send the updated webrev set.
With kind regards,
Ivan
On 3/27/18 6:47 AM, Chris Hegarty wrote:
Ivan,
On 26 Mar 2018, at 23:08, Ivan Gerasimov wrote:
Hello everyone!
A few modifications were done to the patch.
Below is the list of u
hanks in advance!
--
With kind regards,
Ivan Gerasimov
Thanks you Chris for reviewing this!
On 4/18/18 9:06 AM, Chris Hegarty wrote:
Ivan,
On 16/04/18 17:29, Ivan Gerasimov wrote:
...
WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/00/webrev/
I think this is mostly good. Just one comment.
I'm not sure that this is correct.
--
Thanks again Chris!
On 4/19/18 1:50 AM, Chris Hegarty wrote:
On 19 Apr 2018, at 09:44, Ivan Gerasimov <mailto:ivan.gerasi...@oracle.com>> wrote:
...
WEBREV:http://cr.openjdk.java.net/~igerasim/8201510/01/webrev/
<http://cr.openjdk.java.net/%7Eigerasim/8201510/01/webrev/>
brevs/8194534/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
The correct links to the Bug and webrev are:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202091
WEBREV: http://cr.openjdk.java.net/~igerasim/8202091/00/webrev/
Sorry for confusion!
With kind regards,
Ivan
On 4/20/18 1:32 PM, Ivan Gerasimov wrote:
Hello!
After integrating the fix for
review this cleanup?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202154
WEBREV: http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
n the same range,
so it can be defined with constants,
- NET_GetDefaultTOS() always returns zero, so it can be removed.
Would you please help review this?
With kind regards,
Ivan
On 4/23/18 2:29 PM, Ivan Gerasimov wrote:
Hello!
Some code in TwoStacksPlainDatagramSocketImpl.c is only relevan
d regards,
Ivan
Thanks, Vyom
On Tuesday 24 April 2018 09:47 AM, Ivan Gerasimov wrote:
Hello again!
A few other files contain obsolete code, so they can be combined
together in one fix.
The webrev was updated in place:
http://cr.openjdk.java.net/~igerasim/8202154/00/webrev/
Here's
you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202558
WEBREV: http://cr.openjdk.java.net/~igerasim/8202558/00/webrev/
Thanks!
--
With kind regards,
Ivan Gerasimov
I just realized that we've got a similar issue in the same file in the
function initLocalIfs().
The webrev was updated in place to fix this issue as well.
With kind regards,
Ivan
On 5/2/18 12:54 PM, Ivan Gerasimov wrote:
Hello!
The function needsLoopbackRoute() calls initLoopbackR
ue is "too" large.
--
With kind regards,
Ivan Gerasimov
functionality
is already supported by a standard API.
--
With kind regards,
Ivan Gerasimov
/~vtewari/8194298/webrev0.4/index.html).
Please find my answers in-line.
Thanks,
vyom
On Saturday 12 May 2018 11:15 AM, Ivan Gerasimov wrote:
Hi Vyom!
1)
src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java
Thank you for fixing ExtendingSocketOption.options0().
It may be b
gards,
Ivan Gerasimov
an
Cheers,
David
On 25/05/2018 6:57 AM, Ivan Gerasimov wrote:
Hello!
On Unix systems several system calls (including pread, read, readv,
recvfrom, recvmsg, send, sendfile, sendmsg, sendto) may set errno to
either EAGAIN or EWOULDBLOCK on the same condition.
On Linux these two constants a
d regards,
Ivan
Cheers,
David
With kind regards,
Ivan
Cheers,
David
On 25/05/2018 6:57 AM, Ivan Gerasimov wrote:
Hello!
On Unix systems several system calls (including pread, read, readv,
recvfrom, recvmsg, send, sendfile, sendmsg, sendto) may set errno
to either EAGAIN or EWOULDBLOCK on the s
Hi Wiijun!
On 5/24/18 10:13 PM, Weijun Wang wrote:
On May 25, 2018, at 11:58 AM, Ivan Gerasimov wrote:
I also wonder whether a smart compiler might not flag code where the errors do
infact have the same value:
if (errno == 11 || errno == 11) ...
At least gcc -O completely removes the
Hi David!
If gcc, then we already have the same test for both constants in code
with no issues.
For example, java.base/unix/native/libnet/SocketInputStream.c, in
NET_ReadWithTimeout():
result = NET_NonBlockingRead(fd, bufP, len);
if (result == -1 && ((errno == EAGAIN) || (err
EWOULDBLOCK:
It is descriptive enough and compiles optimally.
Fortunately, we don't have to care about it now, as the fix only adds
checks of errno right after calls to system functions and does not store
the errno value anywhere to analyze it later.
--
With kind regards,
Ivan Gerasimov
:
http://cr.openjdk.java.net/~mbaesken/webrevs/8205342/
<http://cr.openjdk.java.net/%7Embaesken/webrevs/8205342/>
Can you fix the line lengths to make it consistent with original code?
That will make it easier to look at side-by-side diffs.
-Alan
--
With kind regards,
Ivan Gerasimov
calls .
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205342.2/
<http://cr.openjdk.java.net/%7Embaesken/webrevs/8205342.2/>
Best regards, Matthias
*From:*Ivan Gerasimov [mailto:ivan.gerasi...@oracle.com]
*Sent:* Samstag, 23. Juni 2018 01:52
*To:* Baesken, Matthias ;
n
used descriptor from another thread to be closed.
"""
Would you please help review a trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8205959
WEBREV: http://cr.openjdk.java.net/~igerasim/8205959/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
o retrying.
With kind regards,
Ivan
--
- DML
On Jun 27, 2018, at 6:15 PM, Ivan Gerasimov <mailto:ivan.gerasi...@oracle.com>> wrote:
Hello!
When closing a socket via NET_SocketClose(int fd), a close(fd) is called.
The later is wrapped in a retry-loop, which is wrong because close()
va.net/~chegar/8207335/webrev.01/
-Chris.
--
With kind regards,
Ivan Gerasimov
It might need analysis to
understand the differences between the draft and RFC 4007 (just in case it
brings up implementation or conformance test issues).
-Alan
--
With kind regards,
Ivan Gerasimov
Nov 2018, at 00:35, Ivan Gerasimov wrote:
Do you want to change ie. -> i.e. here as well:
src/java.base/windows/native/libnet/net_util_md.c
- * 2. If the reqeusted port is 0 (ie. any port) then we try to bind in v4 space
+ * 2. If the requested port is 0 (ie. any port) then we try to
t/net_util_md.c
+ * 2. If the requested port is 0 (ie. any port) then we try to bind in
v4 space
I still see `ie.`.
Not like it really matters in this context :)
With kind regards,
Ivan
On 11/13/18 2:29 PM, Ivan Gerasimov wrote:
Thanks Pavel, looks good!
*src/java.base/share/classes/sun/n
regards,
Ivan Gerasimov
close(f);
684 return;
685 }
Best regards, Matthias
Date: Thu, 10 Jan 2019 20:29:08 -0800
From: Ivan Gerasimov
To: "net-dev@openjdk.java.net"
Subject: RFR 8007606 : Handle realloc() failure in
unix/native/libnet/net_util_md.c correctly
Message-ID:
return;
685 }
Best regards, Matthias
Date: Thu, 10 Jan 2019 20:29:08 -0800
From: Ivan Gerasimov
To: "net-dev@openjdk.java.net"
Subject: RFR 8007606 : Handle realloc() failure in
unix/native/libnet/net_util_md.c correctly
Message-ID: <3dc3c
return;
685 }
Best regards, Matthias
Date: Thu, 10 Jan 2019 20:29:08 -0800
From: Ivan Gerasimov
To: "net-dev@openjdk.java.net"
Subject: RFR 8007606 : Handle realloc() failure in
unix/native/libnet/net_util_md.c correctly
Message-ID: <3dc3c
Hello!
Do you think it is good to go now?
With kind regards,
Ivan
On 1/11/19 11:30 AM, Ivan Gerasimov wrote:
Good catch, thank you!
Indeed, if we don't reset localifsSize then we could end up accessing
already freed memory, which is worse than just a memory leak.
Here's t
e too (not a Reviewer however).
Do you think we should address the other reallocs with unhandeled return code
?
Best regards, Matthias
-Original Message-
From: Langer, Christoph
Sent: Dienstag, 15. Januar 2019 20:58
To: Ivan Gerasimov ; Baesken, Matthias
; net-dev@openjdk.jav
/8170494/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
eptionOccurred(env)" ) call.
Java_java_net_NetworkInterface_getByInetAddress0 may return NULL if
there were no interfaces found.
We should not return from getMulticastInterface() in this case.
With kind regards,
Ivan
Thanks,
Vyom
On Wed, Mar 20, 2019 at 9:49 PM Ivan Gerasimov
mailto:iv
ll the methods
from the other locations. There are already getLastErrorString() and
getErrorString() for chars here.
Also, I am not sure how to test this effectively. The code passes all
tiers as-is.
Thanks,
Brian
--
With kind regards,
Ivan Gerasimov
ease see comments inline below.
On Jun 11, 2019, at 5:06 PM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
Inet4AddressImpl.c:
1) There is an extra space after FormatMessage,
Fixed.
2) It is preexisting. The code doesn't check if FormatMessage failed
to allocate the
if (n > 0) {
NET_ThrowNew(env, err, buf);
LocalFree(buf);
} else {
NET_ThrowNew(env, err, "FormatMessage failed");
}
After all, an error *did* occur.
--
With kind regards,
Ivan Gerasimov
m) will be executed.
The fix does not change the behavior, but helps avoid unnecessary calls
to impliesIgnoreMask().
Would you please help review a trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415
WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thank you Sean for reviewing!
With kind regards,
Ivan
On 9/27/19 7:20 AM, Sean Mullan wrote:
Hi Ivan,
The fix looks good. Good catch.
--Sean
On 8/30/19 7:32 PM, Ivan Gerasimov wrote:
Hello!
In the two implementations of
PermissionCollection.implies(Permission), all the permissions are
with a leading comma.
Would you please help review a simple fix, which will make the behavior
more consistent?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
--
With kind regards,
Ivan Gerasimov
penjdk.java.net/~igerasim/8230407/01/webrev/
With kind regards,
Ivan
On 10/2/19 6:44 AM, Chris Hegarty wrote:
Ivan,
On 01/10/2019 21:26, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
It's not like if we used to allow commas in arbitrary places and stopped
doing that. Instead, it just turned out that the code fails to catch
one specific pattern of malformed action list.
With kind regards,
Ivan
Cheers,
-Joe
On 10/2/2019 4:26 PM, Ivan Gerasimov wrote:
Hi Chris!
Than
On 10/2/19 11:40 PM, Peter Levart wrote:
Hi Ivan,
On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
If the list is malformed, then the constructors throw
IllegalArgumentExce
Hi Chris!
On 10/3/19 8:05 AM, Chris Hegarty wrote:
Ivan,
On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote:
...
So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the
addition of @throws paragraph in the javadoc of SocketPermission.
I would really appreciate it, if
you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233886
WEBREV: http://cr.openjdk.java.net/~igerasim/8233886/00/webrev/
--
With kind regards,
Ivan Gerasimov
/browse/JDK-8044365
WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/
Mach5 control build in progress.
--
With kind regards,
Ivan Gerasimov
1 - 100 of 116 matches
Mail list logo
