Updated webrev: http://cr.openjdk.java.net/~khazra/7158636/webrev.01/
Windows has a more secure version of snprintf and I used that:
http://msdn.microsoft.com/en-us/library/f30dzcf6%28v=vs.110%29.aspx
Thanks,
Kurchi
On 4/17/2012 12:24 PM, Chris Hegarty wrote:
On 17/04/12 20:14, Alan Bateman
On 17/04/12 20:14, Alan Bateman wrote:
On 17/04/2012 19:47, Kurchi Hazra wrote:
Hi,
In Windows Vista and later, InterfaceAddress.getBroadcast() returns
0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of
MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to
handle
Changeset: 1757f049e8c0
Author:khazra
Date: 2012-04-17 12:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1757f049e8c0
7157893: Warnings Cleanup in java.util.*
Summary: Minor code changes to cleanup warnings in java.util.*
Reviewed-by: mduigou, naoto, smarks
Contributed-by:
On 17/04/2012 19:47, Kurchi Hazra wrote:
Hi,
In Windows Vista and later, InterfaceAddress.getBroadcast() returns
0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of
MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to
handle IF_TYPE_IEEE80211 in the relevant swit
Changeset: 31c15e2f51ba
Author:khazra
Date: 2012-04-17 11:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31c15e2f51ba
7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows
Summary: Remove usage of HTTP Server at test/sun/net/www/httptest
Reviewed-by:
On 17/04/12 19:47, Kurchi Hazra wrote:
Hi,
In Windows Vista and later, InterfaceAddress.getBroadcast() returns
0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of
MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to
handle IF_TYPE_IEEE80211 in the relevant switch
s
Hi,
In Windows Vista and later, InterfaceAddress.getBroadcast() returns
0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of
MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to
handle IF_TYPE_IEEE80211 in the relevant switch
statement. While doing this, I also upd
ship it!
-Chris.
On 17/04/12 19:27, Kurchi Hazra wrote:
Updated webrev:
http://cr.openjdk.java.net/~khazra/7152856/webrev.02/
Alan: On second thoughts, both is and os were not required at all. I
removed them.
- Kurchi
On 4/17/2012 8:47 AM, Kurchi Subhra Hazra wrote:
I think the HTTP spec n
Updated webrev:
http://cr.openjdk.java.net/~khazra/7152856/webrev.02/
Alan: On second thoughts, both is and os were not required at all. I
removed them.
- Kurchi
On 4/17/2012 8:47 AM, Kurchi Subhra Hazra wrote:
I think the HTTP spec needs an http server to handle LF gracefully,
although it
Changeset: cce6147632cf
Author:dcubed
Date: 2012-04-17 09:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cce6147632cf
7159320: change default ZIP_DEBUGINFO_FILES back to '1' after fix for 7133529
is available
Reviewed-by: ohair, jmelvin, sspitsyn
! make/common/Defs-linux
Changeset: 869f53f58692
Author:sla
Date: 2012-04-17 06:45 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869f53f58692
7147848: com.sun.management.UnixOperatingSystem uses hardcoded dummy values
[macosx]
Summary: Provide the missing implementation UnixOperatingSystem on Mac O
I think the HTTP spec needs an http server to handle LF gracefully,
although it expects a CRLF, and that is how this is working.
It is a small change, I will anyway correct it.
- Kurchi
On 4/17/12 3:24 AM, Chris Hegarty wrote:
On 16/04/12 22:18, Kurchi Hazra wrote:
Hi,
Thanks for the review
Changeset: 9c1d7507ca37
Author:alanb
Date: 2012-04-17 15:46 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c1d7507ca37
7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with
"Address already in use"
Reviewed-by: alanb, chegar
Contributed-by: jim.g...@oracl
Changeset: b700f85a8f29
Author:robm
Date: 2012-04-17 07:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b700f85a8f29
7118373: (se) Potential leak file descriptor when deregistrating at around the
same time as an async close
Reviewed-by: alanb
! src/share/classes/sun/nio/c
Changeset: d09775066f8a
Author:dmeetry
Date: 2012-04-17 16:13 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d09775066f8a
7015981: java.net.HttpCookie.domainMatches returns false if domain doesn't
start with a dot
Reviewed-by: chegar
! src/share/classes/java/net/HttpCookie.
Thanks Chris. Right, RFC itself contains the statements that can lead to
ambiguity and including examples from different sections of RFC w/o a
proper context doesn't help with understanding what the method should do
and what shouldn't. I'll go ahead and push the fix.
thanks,
dmeetry
On 04/1
On 16/04/12 22:18, Kurchi Hazra wrote:
Hi,
Thanks for the reviews. Here is an updated webrev:
http://cr.openjdk.java.net/~khazra/7152856/webrev.01
The updated webrev looks ok, but the "canned" HTTP response looks funny.
Each HTTP header must be followed by a CRLF ( '\r\n' ), and the end of
t
On 16/04/2012 22:18, Kurchi Hazra wrote:
Hi,
Thanks for the reviews. Here is an updated webrev:
http://cr.openjdk.java.net/~khazra/7152856/webrev.01
Looks okay to me. I guess "is" and "os" could be locals but it's a minor
comment (and no need to generate another webrev if you decide to move
18 matches
Mail list logo
