From nancy.nigam at oracle.com  Fri Sep  2 10:03:04 2016
From: nancy.nigam at oracle.com (Nancy Nigam)
Date: Fri, 2 Sep 2016 15:33:04 +0530
Subject: <i18n dev> Request for Review: JDK-8164791: update i18n test cases
 in test/java/text/Format
Message-ID: <3e8fcdfd-663b-1681-4c81-10fd8d762011@oracle.com>

Hi,

Please review the fix for JDK-8164791.

Bug : https://bugs.openjdk.java.net/browse/JDK-8164791

Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8164791/webrev.06/

Fix : Updated I18n test cases in test/java/text/Format for deprecated 
APIs, AutoBoxing/Unboxing, Iterators etc.

Regards,

Nancy Nigam


From nancy.nigam at oracle.com  Fri Sep  2 09:20:44 2016
From: nancy.nigam at oracle.com (Nancy Nigam)
Date: Fri, 2 Sep 2016 14:50:44 +0530
Subject: <i18n dev> Request for Review: JDK-8164791: update i18n test cases
 in test/java/text/Format
Message-ID: <69ff9e2e-fbe1-a9f6-b5f0-94eeff929b5b@oracle.com>

Hi,

Please review the fix for JDK-8164791.

Bug : https://bugs.openjdk.java.net/browse/JDK-8164791

Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8164791/webrev.06/

Fix : Updated I18n test cases in test/java/text/Format for deprecated 
APIs, AutoBoxing/Unboxing, Iterators etc.

Regards,

Nancy Nigam


From masayoshi.okutsu at oracle.com  Wed Sep  7 22:53:45 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 8 Sep 2016 07:53:45 +0900
Subject: <i18n dev> Request for Review: JDK-8164791: update i18n test
 cases in test/java/text/Format
In-Reply-To: <69ff9e2e-fbe1-a9f6-b5f0-94eeff929b5b@oracle.com>
References: <69ff9e2e-fbe1-a9f6-b5f0-94eeff929b5b@oracle.com>
Message-ID: <69d593fb-071f-9160-7f81-8306e4ee6c5e@oracle.com>

Looks good.

Masayoshi


On 9/2/2016 6:20 PM, Nancy Nigam wrote:
> Hi,
>
> Please review the fix for JDK-8164791.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8164791
>
> Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8164791/webrev.06/
>
> Fix : Updated I18n test cases in test/java/text/Format for deprecated 
> APIs, AutoBoxing/Unboxing, Iterators etc.
>
> Regards,
>
> Nancy Nigam
>


From philip.race at oracle.com  Thu Sep  8 20:12:38 2016
From: philip.race at oracle.com (Philip Race)
Date: Thu, 08 Sep 2016 13:12:38 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <57D1C59A.20805@oracle.com>
References: <57D1C59A.20805@oracle.com>
Message-ID: <57D1C636.5050601@oracle.com>

[Fix i18n-dev address]

-phil.

On 9/8/16, 1:10 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>
> Solaris 10 is not supported by JDK 9.
> This updates the fontconfig file to focus on the default set of fonts
> installed on Solaris 11 as part its desktop.
>
> Preference is given to the Arial, Times New Roman, and Courier New fonts
> that are included with Solaris, as well as other monotype fonts.
> Dejavau Sans is listed for some fallback coverage of less commonly used
> unicode blocks.
>
> 10646-1 encoding is referenced so as to reduce the number of entries.
> More UTF 8 locales were added since that is the default on Solaris 11.
>
> -phil.
>
>

From christoph.langer at sap.com  Tue Sep 13 12:35:36 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 13 Sep 2016 12:35:36 +0000
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
	when seaching	timezone info files
In-Reply-To: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
Message-ID: <a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>

Hi Thomas,

your change looks good. I'm also forwarding this to i18n-dev as issues in TimeZone implementation are mostly handled there.

One remark: Can you take the opportunity to also remove the blank between the cast and malloc in line 150: "(struct dirent64 *) malloc..."?

Unfortunately I'm no reviewer, so you still need an official review.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
> Of Thomas St?fe
> Sent: Dienstag, 13. September 2016 12:54
> To: Java Core Libs <core-libs-dev at openjdk.java.net>
> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
> timezone info files
> 
> Dear all,
> 
> please take a look at this small change:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-
> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
> 
> readdir_r is used to iterate over the content of a system directory, but
> the buffer passed to it is too small: Its size should include the size of
> the dirent structure itself (minus the d_name member).
> 
> The fix also now checks the return code of pathconf(), and if pathconf()
> returns an error, falls back to the NAME_MAX compile time constant.
> Finally, it imposes a minimum size for the buffer, because on older System
> V systems NAME_MAX may be surprisingly small and readdir_r will not check
> the output buffer size. I think it is better to err on the safe side here.
> 
> Kind Regards, Thomas

From masayoshi.okutsu at oracle.com  Tue Sep 13 15:25:34 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 14 Sep 2016 00:25:34 +0900
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
Message-ID: <aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>

Looks good to me. Thank you for fixing this bug!

Masayoshi


On 9/13/2016 11:49 PM, Thomas St?fe wrote:
> Hi Christoph, thanks for your review! Yes, I can remove the blank.
>
> Kind Regards, Thomas
>
> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph <christoph.langer at sap.com
>> wrote:
>> Hi Thomas,
>>
>> your change looks good. I'm also forwarding this to i18n-dev as issues in
>> TimeZone implementation are mostly handled there.
>>
>> One remark: Can you take the opportunity to also remove the blank between
>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."?
>>
>> Unfortunately I'm no reviewer, so you still need an official review.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>> Behalf
>>> Of Thomas St?fe
>>> Sent: Dienstag, 13. September 2016 12:54
>>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
>>> timezone info files
>>>
>>> Dear all,
>>>
>>> please take a look at this small change:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>> Potential-Heap-buffer-
>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>
>>> readdir_r is used to iterate over the content of a system directory, but
>>> the buffer passed to it is too small: Its size should include the size of
>>> the dirent structure itself (minus the d_name member).
>>>
>>> The fix also now checks the return code of pathconf(), and if pathconf()
>>> returns an error, falls back to the NAME_MAX compile time constant.
>>> Finally, it imposes a minimum size for the buffer, because on older
>> System
>>> V systems NAME_MAX may be surprisingly small and readdir_r will not check
>>> the output buffer size. I think it is better to err on the safe side
>> here.
>>> Kind Regards, Thomas


From thomas.stuefe at gmail.com  Tue Sep 13 14:49:51 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 13 Sep 2016 16:49:51 +0200
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
Message-ID: <CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>

Hi Christoph, thanks for your review! Yes, I can remove the blank.

Kind Regards, Thomas

On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph <christoph.langer at sap.com
> wrote:

> Hi Thomas,
>
> your change looks good. I'm also forwarding this to i18n-dev as issues in
> TimeZone implementation are mostly handled there.
>
> One remark: Can you take the opportunity to also remove the blank between
> the cast and malloc in line 150: "(struct dirent64 *) malloc..."?
>
> Unfortunately I'm no reviewer, so you still need an official review.
>
> Best regards
> Christoph
>
> > -----Original Message-----
> > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf
> > Of Thomas St?fe
> > Sent: Dienstag, 13. September 2016 12:54
> > To: Java Core Libs <core-libs-dev at openjdk.java.net>
> > Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
> > timezone info files
> >
> > Dear all,
> >
> > please take a look at this small change:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
> > Webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
> Potential-Heap-buffer-
> > overflow-when-seaching-timezone-info-files/webrev.00/webrev/
> >
> > readdir_r is used to iterate over the content of a system directory, but
> > the buffer passed to it is too small: Its size should include the size of
> > the dirent structure itself (minus the d_name member).
> >
> > The fix also now checks the return code of pathconf(), and if pathconf()
> > returns an error, falls back to the NAME_MAX compile time constant.
> > Finally, it imposes a minimum size for the buffer, because on older
> System
> > V systems NAME_MAX may be surprisingly small and readdir_r will not check
> > the output buffer size. I think it is better to err on the safe side
> here.
> >
> > Kind Regards, Thomas
>

From naoto.sato at oracle.com  Wed Sep 14 00:28:18 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Sep 2016 17:28:18 -0700
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
Message-ID: <027936ea-731f-6931-86bd-d7020ce8138f@oracle.com>

Hi Thomas,

Another cosmetic comment: please use 4 space indentation inside those 
"if" clauses. Otherwise, +1.

Naoto

On 9/13/16 7:49 AM, Thomas St?fe wrote:
> Hi Christoph, thanks for your review! Yes, I can remove the blank.
>
> Kind Regards, Thomas
>
> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph <christoph.langer at sap.com
>> wrote:
>
>> Hi Thomas,
>>
>> your change looks good. I'm also forwarding this to i18n-dev as issues in
>> TimeZone implementation are mostly handled there.
>>
>> One remark: Can you take the opportunity to also remove the blank between
>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."?
>>
>> Unfortunately I'm no reviewer, so you still need an official review.
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>> Behalf
>>> Of Thomas St?fe
>>> Sent: Dienstag, 13. September 2016 12:54
>>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
>>> timezone info files
>>>
>>> Dear all,
>>>
>>> please take a look at this small change:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>> Potential-Heap-buffer-
>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>
>>> readdir_r is used to iterate over the content of a system directory, but
>>> the buffer passed to it is too small: Its size should include the size of
>>> the dirent structure itself (minus the d_name member).
>>>
>>> The fix also now checks the return code of pathconf(), and if pathconf()
>>> returns an error, falls back to the NAME_MAX compile time constant.
>>> Finally, it imposes a minimum size for the buffer, because on older
>> System
>>> V systems NAME_MAX may be surprisingly small and readdir_r will not check
>>> the output buffer size. I think it is better to err on the safe side
>> here.
>>>
>>> Kind Regards, Thomas
>>

From naoto.sato at oracle.com  Wed Sep 14 04:04:47 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Sep 2016 21:04:47 -0700
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <027936ea-731f-6931-86bd-d7020ce8138f@oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<027936ea-731f-6931-86bd-d7020ce8138f@oracle.com>
Message-ID: <b19d1725-bc6b-682f-d160-0921d297cf79@oracle.com>

Line 137: The declaration of "min" cannot follow statements (not all 
platforms support C99). It has to move up around line 131.

Naoto

On 9/13/16 5:28 PM, Naoto Sato wrote:
> Hi Thomas,
>
> Another cosmetic comment: please use 4 space indentation inside those
> "if" clauses. Otherwise, +1.
>
> Naoto
>
> On 9/13/16 7:49 AM, Thomas St?fe wrote:
>> Hi Christoph, thanks for your review! Yes, I can remove the blank.
>>
>> Kind Regards, Thomas
>>
>> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>> <christoph.langer at sap.com
>>> wrote:
>>
>>> Hi Thomas,
>>>
>>> your change looks good. I'm also forwarding this to i18n-dev as
>>> issues in
>>> TimeZone implementation are mostly handled there.
>>>
>>> One remark: Can you take the opportunity to also remove the blank
>>> between
>>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."?
>>>
>>> Unfortunately I'm no reviewer, so you still need an official review.
>>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>> Behalf
>>>> Of Thomas St?fe
>>>> Sent: Dienstag, 13. September 2016 12:54
>>>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
>>>> timezone info files
>>>>
>>>> Dear all,
>>>>
>>>> please take a look at this small change:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>>> Potential-Heap-buffer-
>>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>>
>>>> readdir_r is used to iterate over the content of a system directory,
>>>> but
>>>> the buffer passed to it is too small: Its size should include the
>>>> size of
>>>> the dirent structure itself (minus the d_name member).
>>>>
>>>> The fix also now checks the return code of pathconf(), and if
>>>> pathconf()
>>>> returns an error, falls back to the NAME_MAX compile time constant.
>>>> Finally, it imposes a minimum size for the buffer, because on older
>>> System
>>>> V systems NAME_MAX may be surprisingly small and readdir_r will not
>>>> check
>>>> the output buffer size. I think it is better to err on the safe side
>>> here.
>>>>
>>>> Kind Regards, Thomas
>>>

From thomas.stuefe at gmail.com  Wed Sep 14 06:34:12 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 14 Sep 2016 08:34:12 +0200
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
Message-ID: <CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>

Hi all,

thanks for the reviews. Here is version two:

http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/

Only cosmetic changes:
- made code pre-c99 compatible
- consistently use dirent64
- fix indentation in ifs
- removed black between malloc and cast

Kind Regards, Thomas



On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu <
masayoshi.okutsu at oracle.com> wrote:

> Looks good to me. Thank you for fixing this bug!
>
> Masayoshi
>
>
>
> On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>
>> Hi Christoph, thanks for your review! Yes, I can remove the blank.
>>
>> Kind Regards, Thomas
>>
>> On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph <
>> christoph.langer at sap.com
>>
>>> wrote:
>>> Hi Thomas,
>>>
>>> your change looks good. I'm also forwarding this to i18n-dev as issues in
>>> TimeZone implementation are mostly handled there.
>>>
>>> One remark: Can you take the opportunity to also remove the blank between
>>> the cast and malloc in line 150: "(struct dirent64 *) malloc..."?
>>>
>>> Unfortunately I'm no reviewer, so you still need an official review.
>>>
>>> Best regards
>>> Christoph
>>>
>>> -----Original Message-----
>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>>>
>>> Behalf
>>>
>>>> Of Thomas St?fe
>>>> Sent: Dienstag, 13. September 2016 12:54
>>>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>>>> Subject: RFR(xs): 8165936: Potential Heap buffer overflow when seaching
>>>> timezone info files
>>>>
>>>> Dear all,
>>>>
>>>> please take a look at this small change:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>>>>
>>> Potential-Heap-buffer-
>>>
>>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>>
>>>> readdir_r is used to iterate over the content of a system directory, but
>>>> the buffer passed to it is too small: Its size should include the size
>>>> of
>>>> the dirent structure itself (minus the d_name member).
>>>>
>>>> The fix also now checks the return code of pathconf(), and if pathconf()
>>>> returns an error, falls back to the NAME_MAX compile time constant.
>>>> Finally, it imposes a minimum size for the buffer, because on older
>>>>
>>> System
>>>
>>>> V systems NAME_MAX may be surprisingly small and readdir_r will not
>>>> check
>>>> the output buffer size. I think it is better to err on the safe side
>>>>
>>> here.
>>>
>>>> Kind Regards, Thomas
>>>>
>>>
>

From Roger.Riggs at Oracle.com  Wed Sep 14 13:50:34 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 14 Sep 2016 09:50:34 -0400
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
Message-ID: <1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com>

+1

On 9/14/2016 2:34 AM, Thomas St?fe wrote:
> Hi all,
>
> thanks for the reviews. Here is version two:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/>
>
> Only cosmetic changes:
> - made code pre-c99 compatible
> - consistently use dirent64
> - fix indentation in ifs
> - removed blank between malloc and cast
>
> Kind Regards, Thomas
>
>
>
> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu 
> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>
>     Looks good to me. Thank you for fixing this bug!
>
>     Masayoshi
>
>
>
>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>
>         Hi Christoph, thanks for your review! Yes, I can remove the blank.
>
>         Kind Regards, Thomas
>
>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>
>             wrote:
>             Hi Thomas,
>
>             your change looks good. I'm also forwarding this to
>             i18n-dev as issues in
>             TimeZone implementation are mostly handled there.
>
>             One remark: Can you take the opportunity to also remove
>             the blank between
>             the cast and malloc in line 150: "(struct dirent64 *)
>             malloc..."?
>
>             Unfortunately I'm no reviewer, so you still need an
>             official review.
>
>             Best regards
>             Christoph
>
>                 -----Original Message-----
>                 From: core-libs-dev
>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>                 <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>
>             Behalf
>
>                 Of Thomas St?fe
>                 Sent: Dienstag, 13. September 2016 12:54
>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>                 <mailto:core-libs-dev at openjdk.java.net>>
>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>                 overflow when seaching
>                 timezone info files
>
>                 Dear all,
>
>                 please take a look at this small change:
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>                 <https://bugs.openjdk.java.net/browse/JDK-8165936>
>                 Webrev:
>                 http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>                 <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>
>             Potential-Heap-buffer-
>
>                 overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>
>                 readdir_r is used to iterate over the content of a
>                 system directory, but
>                 the buffer passed to it is too small: Its size should
>                 include the size of
>                 the dirent structure itself (minus the d_name member).
>
>                 The fix also now checks the return code of pathconf(),
>                 and if pathconf()
>                 returns an error, falls back to the NAME_MAX compile
>                 time constant.
>                 Finally, it imposes a minimum size for the buffer,
>                 because on older
>
>             System
>
>                 V systems NAME_MAX may be surprisingly small and
>                 readdir_r will not check
>                 the output buffer size. I think it is better to err on
>                 the safe side
>
>             here.
>
>                 Kind Regards, Thomas
>
>
>


From naoto.sato at oracle.com  Wed Sep 14 14:58:48 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 14 Sep 2016 07:58:48 -0700
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
	<1849efb3-d8de-a885-9e35-d0e3c7afa292@Oracle.com>
Message-ID: <f17f8b71-efde-a6ea-4433-40eda1b667f1@oracle.com>

+1

Naoto

On 9/14/16 6:50 AM, Roger Riggs wrote:
> +1
>
> On 9/14/2016 2:34 AM, Thomas St?fe wrote:
>> Hi all,
>>
>> thanks for the reviews. Here is version two:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/
>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/>
>>
>> Only cosmetic changes:
>> - made code pre-c99 compatible
>> - consistently use dirent64
>> - fix indentation in ifs
>> - removed blank between malloc and cast
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu
>> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>>
>>     Looks good to me. Thank you for fixing this bug!
>>
>>     Masayoshi
>>
>>
>>
>>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>>
>>         Hi Christoph, thanks for your review! Yes, I can remove the blank.
>>
>>         Kind Regards, Thomas
>>
>>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>>
>>             wrote:
>>             Hi Thomas,
>>
>>             your change looks good. I'm also forwarding this to
>>             i18n-dev as issues in
>>             TimeZone implementation are mostly handled there.
>>
>>             One remark: Can you take the opportunity to also remove
>>             the blank between
>>             the cast and malloc in line 150: "(struct dirent64 *)
>>             malloc..."?
>>
>>             Unfortunately I'm no reviewer, so you still need an
>>             official review.
>>
>>             Best regards
>>             Christoph
>>
>>                 -----Original Message-----
>>                 From: core-libs-dev
>>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>>                 <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>>
>>             Behalf
>>
>>                 Of Thomas St?fe
>>                 Sent: Dienstag, 13. September 2016 12:54
>>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>>                 <mailto:core-libs-dev at openjdk.java.net>>
>>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>>                 overflow when seaching
>>                 timezone info files
>>
>>                 Dear all,
>>
>>                 please take a look at this small change:
>>
>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>                 <https://bugs.openjdk.java.net/browse/JDK-8165936>
>>                 Webrev:
>>                 http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>>                 <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>>
>>             Potential-Heap-buffer-
>>
>>                 overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>
>>                 readdir_r is used to iterate over the content of a
>>                 system directory, but
>>                 the buffer passed to it is too small: Its size should
>>                 include the size of
>>                 the dirent structure itself (minus the d_name member).
>>
>>                 The fix also now checks the return code of pathconf(),
>>                 and if pathconf()
>>                 returns an error, falls back to the NAME_MAX compile
>>                 time constant.
>>                 Finally, it imposes a minimum size for the buffer,
>>                 because on older
>>
>>             System
>>
>>                 V systems NAME_MAX may be surprisingly small and
>>                 readdir_r will not check
>>                 the output buffer size. I think it is better to err on
>>                 the safe side
>>
>>             here.
>>
>>                 Kind Regards, Thomas
>>
>>
>>
>

From Roger.Riggs at Oracle.com  Thu Sep 15 17:39:13 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 15 Sep 2016 13:39:13 -0400
Subject: <i18n dev> RFR(xs): 8165936: Potential Heap buffer overflow
 when seaching timezone info files
In-Reply-To: <CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
Message-ID: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com>

Hi Thomas,

It looks like NAME_MAX is not defined on Solaris and breaks the build on 
Solaris. [1]

An  alternative would be to conditionally use PATH_MAX.

But I think it would be reasonable to just remove the use of NAME_MAX, 
since the following
code increases the value to at least 1024, which should be safe.

If you don't have time to address this, I can propose a fix.

Roger

[1] 8166148  fix for JDK-8165936 broke solaris builds 
<https://bugs.openjdk.java.net/browse/JDK-8166148>


On 9/14/2016 2:34 AM, Thomas St?fe wrote:
> Hi all,
>
> thanks for the reviews. Here is version two:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/>
>
> Only cosmetic changes:
> - made code pre-c99 compatible
> - consistently use dirent64
> - fix indentation in ifs
> - removed black between malloc and cast
>
> Kind Regards, Thomas
>
>
>
> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu 
> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>
>     Looks good to me. Thank you for fixing this bug!
>
>     Masayoshi
>
>
>
>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>
>         Hi Christoph, thanks for your review! Yes, I can remove the blank.
>
>         Kind Regards, Thomas
>
>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>
>             wrote:
>             Hi Thomas,
>
>             your change looks good. I'm also forwarding this to
>             i18n-dev as issues in
>             TimeZone implementation are mostly handled there.
>
>             One remark: Can you take the opportunity to also remove
>             the blank between
>             the cast and malloc in line 150: "(struct dirent64 *)
>             malloc..."?
>
>             Unfortunately I'm no reviewer, so you still need an
>             official review.
>
>             Best regards
>             Christoph
>
>                 -----Original Message-----
>                 From: core-libs-dev
>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>                 <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>
>             Behalf
>
>                 Of Thomas St?fe
>                 Sent: Dienstag, 13. September 2016 12:54
>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>                 <mailto:core-libs-dev at openjdk.java.net>>
>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>                 overflow when seaching
>                 timezone info files
>
>                 Dear all,
>
>                 please take a look at this small change:
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>                 <https://bugs.openjdk.java.net/browse/JDK-8165936>
>                 Webrev:
>                 http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>                 <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>
>             Potential-Heap-buffer-
>
>                 overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>
>                 readdir_r is used to iterate over the content of a
>                 system directory, but
>                 the buffer passed to it is too small: Its size should
>                 include the size of
>                 the dirent structure itself (minus the d_name member).
>
>                 The fix also now checks the return code of pathconf(),
>                 and if pathconf()
>                 returns an error, falls back to the NAME_MAX compile
>                 time constant.
>                 Finally, it imposes a minimum size for the buffer,
>                 because on older
>
>             System
>
>                 V systems NAME_MAX may be surprisingly small and
>                 readdir_r will not check
>                 the output buffer size. I think it is better to err on
>                 the safe side
>
>             here.
>
>                 Kind Regards, Thomas
>
>
>


From Roger.Riggs at Oracle.com  Thu Sep 15 19:16:21 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 15 Sep 2016 15:16:21 -0400
Subject: <i18n dev> RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds
In-Reply-To: <00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
	<00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com>
Message-ID: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com>

Please review a fix for build breakage on Solaris.
The NAME_MAX value does not seem to add much value in this case and is 
not defined on all supported platforms.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/
Issue:
    https://bugs.openjdk.java.net/browse/JDK-8166148

Thanks, Roger


On 9/15/2016 1:39 PM, Roger Riggs wrote:
> Hi Thomas,
>
> It looks like NAME_MAX is not defined on Solaris and breaks the build 
> on Solaris. [1]
>
> An  alternative would be to conditionally use PATH_MAX.
>
> But I think it would be reasonable to just remove the use of NAME_MAX, 
> since the following
> code increases the value to at least 1024, which should be safe.
>
> If you don't have time to address this, I can propose a fix.
>
> Roger
>
> [1] 8166148  fix for JDK-8165936 broke solaris builds 
> <https://bugs.openjdk.java.net/browse/JDK-8166148>
>
>
> On 9/14/2016 2:34 AM, Thomas St?fe wrote:
>> Hi all,
>>
>> thanks for the reviews. Here is version two:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ 
>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/> 
>>
>>
>> Only cosmetic changes:
>> - made code pre-c99 compatible
>> - consistently use dirent64
>> - fix indentation in ifs
>> - removed black between malloc and cast
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu 
>> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> 
>> wrote:
>>
>>     Looks good to me. Thank you for fixing this bug!
>>
>>     Masayoshi
>>
>>
>>
>>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>>
>>         Hi Christoph, thanks for your review! Yes, I can remove the 
>> blank.
>>
>>         Kind Regards, Thomas
>>
>>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>>
>>             wrote:
>>             Hi Thomas,
>>
>>             your change looks good. I'm also forwarding this to
>>             i18n-dev as issues in
>>             TimeZone implementation are mostly handled there.
>>
>>             One remark: Can you take the opportunity to also remove
>>             the blank between
>>             the cast and malloc in line 150: "(struct dirent64 *)
>>             malloc..."?
>>
>>             Unfortunately I'm no reviewer, so you still need an
>>             official review.
>>
>>             Best regards
>>             Christoph
>>
>>                 -----Original Message-----
>>                 From: core-libs-dev
>>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>> <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>>
>>             Behalf
>>
>>                 Of Thomas St?fe
>>                 Sent: Dienstag, 13. September 2016 12:54
>>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>> <mailto:core-libs-dev at openjdk.java.net>>
>>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>>                 overflow when seaching
>>                 timezone info files
>>
>>                 Dear all,
>>
>>                 please take a look at this small change:
>>
>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>> <https://bugs.openjdk.java.net/browse/JDK-8165936>
>>                 Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>>
>>             Potential-Heap-buffer-
>>
>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>
>>                 readdir_r is used to iterate over the content of a
>>                 system directory, but
>>                 the buffer passed to it is too small: Its size should
>>                 include the size of
>>                 the dirent structure itself (minus the d_name member).
>>
>>                 The fix also now checks the return code of pathconf(),
>>                 and if pathconf()
>>                 returns an error, falls back to the NAME_MAX compile
>>                 time constant.
>>                 Finally, it imposes a minimum size for the buffer,
>>                 because on older
>>
>>             System
>>
>>                 V systems NAME_MAX may be surprisingly small and
>>                 readdir_r will not check
>>                 the output buffer size. I think it is better to err on
>>                 the safe side
>>
>>             here.
>>
>>                 Kind Regards, Thomas
>>
>>
>>
>


From naoto.sato at oracle.com  Thu Sep 15 19:42:02 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 15 Sep 2016 12:42:02 -0700
Subject: <i18n dev> RFR 9: 8166148 Fix for JDK-8165936 broke Solaris
 builds
In-Reply-To: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
	<00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com>
	<949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com>
Message-ID: <68a16c00-b24b-89cb-4121-c7a8e1f837ec@oracle.com>

+1

Naoto

On 9/15/16 12:16 PM, Roger Riggs wrote:
> Please review a fix for build breakage on Solaris.
> The NAME_MAX value does not seem to add much value in this case and is
> not defined on all supported platforms.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8166148
>
> Thanks, Roger
>
>
> On 9/15/2016 1:39 PM, Roger Riggs wrote:
>> Hi Thomas,
>>
>> It looks like NAME_MAX is not defined on Solaris and breaks the build
>> on Solaris. [1]
>>
>> An  alternative would be to conditionally use PATH_MAX.
>>
>> But I think it would be reasonable to just remove the use of NAME_MAX,
>> since the following
>> code increases the value to at least 1024, which should be safe.
>>
>> If you don't have time to address this, I can propose a fix.
>>
>> Roger
>>
>> [1] 8166148  fix for JDK-8165936 broke solaris builds
>> <https://bugs.openjdk.java.net/browse/JDK-8166148>
>>
>>
>> On 9/14/2016 2:34 AM, Thomas St?fe wrote:
>>> Hi all,
>>>
>>> thanks for the reviews. Here is version two:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/
>>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/>
>>>
>>>
>>> Only cosmetic changes:
>>> - made code pre-c99 compatible
>>> - consistently use dirent64
>>> - fix indentation in ifs
>>> - removed black between malloc and cast
>>>
>>> Kind Regards, Thomas
>>>
>>>
>>>
>>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu
>>> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>>
>>> wrote:
>>>
>>>     Looks good to me. Thank you for fixing this bug!
>>>
>>>     Masayoshi
>>>
>>>
>>>
>>>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>>>
>>>         Hi Christoph, thanks for your review! Yes, I can remove the
>>> blank.
>>>
>>>         Kind Regards, Thomas
>>>
>>>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>>>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>>>
>>>             wrote:
>>>             Hi Thomas,
>>>
>>>             your change looks good. I'm also forwarding this to
>>>             i18n-dev as issues in
>>>             TimeZone implementation are mostly handled there.
>>>
>>>             One remark: Can you take the opportunity to also remove
>>>             the blank between
>>>             the cast and malloc in line 150: "(struct dirent64 *)
>>>             malloc..."?
>>>
>>>             Unfortunately I'm no reviewer, so you still need an
>>>             official review.
>>>
>>>             Best regards
>>>             Christoph
>>>
>>>                 -----Original Message-----
>>>                 From: core-libs-dev
>>>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>>> <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>>>
>>>             Behalf
>>>
>>>                 Of Thomas St?fe
>>>                 Sent: Dienstag, 13. September 2016 12:54
>>>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>>> <mailto:core-libs-dev at openjdk.java.net>>
>>>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>>>                 overflow when seaching
>>>                 timezone info files
>>>
>>>                 Dear all,
>>>
>>>                 please take a look at this small change:
>>>
>>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>> <https://bugs.openjdk.java.net/browse/JDK-8165936>
>>>                 Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>>>
>>>             Potential-Heap-buffer-
>>>
>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>
>>>                 readdir_r is used to iterate over the content of a
>>>                 system directory, but
>>>                 the buffer passed to it is too small: Its size should
>>>                 include the size of
>>>                 the dirent structure itself (minus the d_name member).
>>>
>>>                 The fix also now checks the return code of pathconf(),
>>>                 and if pathconf()
>>>                 returns an error, falls back to the NAME_MAX compile
>>>                 time constant.
>>>                 Finally, it imposes a minimum size for the buffer,
>>>                 because on older
>>>
>>>             System
>>>
>>>                 V systems NAME_MAX may be surprisingly small and
>>>                 readdir_r will not check
>>>                 the output buffer size. I think it is better to err on
>>>                 the safe side
>>>
>>>             here.
>>>
>>>                 Kind Regards, Thomas
>>>
>>>
>>>
>>
>

From thomas.stuefe at gmail.com  Thu Sep 15 20:56:55 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 15 Sep 2016 22:56:55 +0200
Subject: <i18n dev> RFR 9: 8166148 Fix for JDK-8165936 broke Solaris
	builds
In-Reply-To: <949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com>
References: <CAA-vtUxeEwT+AXnes1QoXBUvkhkpXOomMVWA=w8WQ1ZmASAWyg@mail.gmail.com>
	<a1499e1fd1e04836b45b96003f607321@DEWDFE13DE11.global.corp.sap>
	<CAA-vtUxvLH9-AzZWGS_2DdeWk-86GfxboCERkjbS_677g9pP0A@mail.gmail.com>
	<aad9a08d-d99a-1b85-d7dc-9db1151c56c4@oracle.com>
	<CAA-vtUwDohc9D5Ce2_NHkpN4HuZFmOr2MyTYGvWtxe_gxMBb6Q@mail.gmail.com>
	<00b6b2a9-e394-18a7-148d-2e82d432a020@Oracle.com>
	<949305e7-4665-1cd5-50fc-228009ba8e70@Oracle.com>
Message-ID: <CAA-vtUwo-kDzKRQ7a9EHzxCbtqfVuLNeOyZCMvBCEOZvHexRRA@mail.gmail.com>

Hi Roger,

Thank you for taking care of this! Fix looks fine.

Kind Regards, Thomas

On Thursday, 15 September 2016, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review a fix for build breakage on Solaris.
> The NAME_MAX value does not seem to add much value in this case and is not
> defined on all supported platforms.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8166148
>
> Thanks, Roger
>
>
> On 9/15/2016 1:39 PM, Roger Riggs wrote:
>
>> Hi Thomas,
>>
>> It looks like NAME_MAX is not defined on Solaris and breaks the build on
>> Solaris. [1]
>>
>> An  alternative would be to conditionally use PATH_MAX.
>>
>> But I think it would be reasonable to just remove the use of NAME_MAX,
>> since the following
>> code increases the value to at least 1024, which should be safe.
>>
>> If you don't have time to address this, I can propose a fix.
>>
>> Roger
>>
>> [1] 8166148  fix for JDK-8165936 broke solaris builds <
>> https://bugs.openjdk.java.net/browse/JDK-8166148>
>>
>>
>> On 9/14/2016 2:34 AM, Thomas St?fe wrote:
>>
>>> Hi all,
>>>
>>> thanks for the reviews. Here is version two:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential
>>> -Heap-buffer-overflow-when-seaching-timezone-info-files/
>>> webrev.01/webrev/ <http://cr.openjdk.java.net/%7
>>> Estuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-
>>> seaching-timezone-info-files/webrev.01/webrev/>
>>>
>>> Only cosmetic changes:
>>> - made code pre-c99 compatible
>>> - consistently use dirent64
>>> - fix indentation in ifs
>>> - removed black between malloc and cast
>>>
>>> Kind Regards, Thomas
>>>
>>>
>>>
>>> On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu <
>>> masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>>>
>>>     Looks good to me. Thank you for fixing this bug!
>>>
>>>     Masayoshi
>>>
>>>
>>>
>>>     On 9/13/2016 11:49 PM, Thomas St?fe wrote:
>>>
>>>         Hi Christoph, thanks for your review! Yes, I can remove the
>>> blank.
>>>
>>>         Kind Regards, Thomas
>>>
>>>         On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
>>>         <christoph.langer at sap.com <mailto:christoph.langer at sap.com>
>>>
>>>             wrote:
>>>             Hi Thomas,
>>>
>>>             your change looks good. I'm also forwarding this to
>>>             i18n-dev as issues in
>>>             TimeZone implementation are mostly handled there.
>>>
>>>             One remark: Can you take the opportunity to also remove
>>>             the blank between
>>>             the cast and malloc in line 150: "(struct dirent64 *)
>>>             malloc..."?
>>>
>>>             Unfortunately I'm no reviewer, so you still need an
>>>             official review.
>>>
>>>             Best regards
>>>             Christoph
>>>
>>>                 -----Original Message-----
>>>                 From: core-libs-dev
>>>                 [mailto:core-libs-dev-bounces at openjdk.java.net
>>> <mailto:core-libs-dev-bounces at openjdk.java.net>] On
>>>
>>>             Behalf
>>>
>>>                 Of Thomas St?fe
>>>                 Sent: Dienstag, 13. September 2016 12:54
>>>                 To: Java Core Libs <core-libs-dev at openjdk.java.net
>>> <mailto:core-libs-dev at openjdk.java.net>>
>>>                 Subject: RFR(xs): 8165936: Potential Heap buffer
>>>                 overflow when seaching
>>>                 timezone info files
>>>
>>>                 Dear all,
>>>
>>>                 please take a look at this small change:
>>>
>>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8165936
>>> <https://bugs.openjdk.java.net/browse/JDK-8165936>
>>>                 Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8165936-
>>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8165936->
>>>
>>>             Potential-Heap-buffer-
>>>
>>> overflow-when-seaching-timezone-info-files/webrev.00/webrev/
>>>
>>>                 readdir_r is used to iterate over the content of a
>>>                 system directory, but
>>>                 the buffer passed to it is too small: Its size should
>>>                 include the size of
>>>                 the dirent structure itself (minus the d_name member).
>>>
>>>                 The fix also now checks the return code of pathconf(),
>>>                 and if pathconf()
>>>                 returns an error, falls back to the NAME_MAX compile
>>>                 time constant.
>>>                 Finally, it imposes a minimum size for the buffer,
>>>                 because on older
>>>
>>>             System
>>>
>>>                 V systems NAME_MAX may be surprisingly small and
>>>                 readdir_r will not check
>>>                 the output buffer size. I think it is better to err on
>>>                 the safe side
>>>
>>>             here.
>>>
>>>                 Kind Regards, Thomas
>>>
>>>
>>>
>>>
>>
>

From nishit.jain at oracle.com  Fri Sep 16 09:09:39 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 16 Sep 2016 14:39:39 +0530
Subject: <i18n dev> Review Request for JDK-8165984: ResourceBundle lookup
 fields not completely thread-safe
Message-ID: <f8bfd012-2eba-e28b-fd4c-c908ff3ee7ba@oracle.com>

Hi,

Please review the fix for JDK-8165984

Bug: https://bugs.openjdk.java.net/browse/JDK-8165984
Webrev: http://cr.openjdk.java.net/~nishjain/8165984/webrev.01/

Fix: the private lookup variable is made final in PropertyResourceBundle 
as after initialization it is not changed anywhere. lookup variable is 
made volatile in ListResourceBundle to make sure that multiple threads 
read the value from main memory.

Regards,
Nishit Jain

From naoto.sato at oracle.com  Fri Sep 16 17:00:48 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 16 Sep 2016 10:00:48 -0700
Subject: <i18n dev> Review Request for JDK-8165984: ResourceBundle
 lookup fields not completely thread-safe
In-Reply-To: <f8bfd012-2eba-e28b-fd4c-c908ff3ee7ba@oracle.com>
References: <f8bfd012-2eba-e28b-fd4c-c908ff3ee7ba@oracle.com>
Message-ID: <e1d3d286-23f1-1935-baed-34fa41477f49@oracle.com>

Looks good.

BTW, I believe making it "final" means to make sure every threads are 
guaranteed to see the same value, not because it is not changed after 
the construction.

Naoto

On 9/16/16 2:09 AM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8165984
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165984
> Webrev: http://cr.openjdk.java.net/~nishjain/8165984/webrev.01/
>
> Fix: the private lookup variable is made final in PropertyResourceBundle
> as after initialization it is not changed anywhere. lookup variable is
> made volatile in ListResourceBundle to make sure that multiple threads
> read the value from main memory.
>
> Regards,
> Nishit Jain

From masayoshi.okutsu at oracle.com  Fri Sep 16 21:51:53 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sat, 17 Sep 2016 06:51:53 +0900
Subject: <i18n dev> Review Request for JDK-8165984: ResourceBundle
 lookup fields not completely thread-safe
In-Reply-To: <e1d3d286-23f1-1935-baed-34fa41477f49@oracle.com>
References: <f8bfd012-2eba-e28b-fd4c-c908ff3ee7ba@oracle.com>
	<e1d3d286-23f1-1935-baed-34fa41477f49@oracle.com>
Message-ID: <ffe65c02-c40a-03f4-5455-44af36f54239@oracle.com>

+1

Masayoshi


On 9/17/2016 2:00 AM, Naoto Sato wrote:
> Looks good.
>
> BTW, I believe making it "final" means to make sure every threads are 
> guaranteed to see the same value, not because it is not changed after 
> the construction.
>
> Naoto
>
> On 9/16/16 2:09 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8165984
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165984
>> Webrev: http://cr.openjdk.java.net/~nishjain/8165984/webrev.01/
>>
>> Fix: the private lookup variable is made final in PropertyResourceBundle
>> as after initialization it is not changed anywhere. lookup variable is
>> made volatile in ListResourceBundle to make sure that multiple threads
>> read the value from main memory.
>>
>> Regards,
>> Nishit Jain


From nishit.jain at oracle.com  Mon Sep 19 07:25:20 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 19 Sep 2016 12:55:20 +0530
Subject: <i18n dev> Review Request for JDK-8165984: ResourceBundle
 lookup fields not completely thread-safe
In-Reply-To: <e1d3d286-23f1-1935-baed-34fa41477f49@oracle.com>
References: <f8bfd012-2eba-e28b-fd4c-c908ff3ee7ba@oracle.com>
	<e1d3d286-23f1-1935-baed-34fa41477f49@oracle.com>
Message-ID: <7aaf67ac-f5d8-76a1-0dd2-cc560012ba00@oracle.com>

Hi Naoto,

Thanks for the review.

Yes, you are correct, I somehow missed to mention the correct reason for 
that.

Regards,
Nishit Jain
On 16-09-2016 22:30, Naoto Sato wrote:
> Looks good.
>
> BTW, I believe making it "final" means to make sure every threads are 
> guaranteed to see the same value, not because it is not changed after 
> the construction.
>
> Naoto
>
> On 9/16/16 2:09 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8165984
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165984
>> Webrev: http://cr.openjdk.java.net/~nishjain/8165984/webrev.01/
>>
>> Fix: the private lookup variable is made final in PropertyResourceBundle
>> as after initialization it is not changed anywhere. lookup variable is
>> made volatile in ListResourceBundle to make sure that multiple threads
>> read the value from main memory.
>>
>> Regards,
>> Nishit Jain


From philip.race at oracle.com  Fri Sep 23 05:08:47 2016
From: philip.race at oracle.com (Philip Race)
Date: Thu, 22 Sep 2016 22:08:47 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <57D1C636.5050601@oracle.com>
References: <57D1C59A.20805@oracle.com> <57D1C636.5050601@oracle.com>
Message-ID: <57E4B8DF.4050704@oracle.com>

PING .. any takers on this two week old RFR ?

-phil.

On 9/8/16, 1:12 PM, Philip Race wrote:
> [Fix i18n-dev address]
>
> -phil.
>
> On 9/8/16, 1:10 PM, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
>> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>>
>> Solaris 10 is not supported by JDK 9.
>> This updates the fontconfig file to focus on the default set of fonts
>> installed on Solaris 11 as part its desktop.
>>
>> Preference is given to the Arial, Times New Roman, and Courier New fonts
>> that are included with Solaris, as well as other monotype fonts.
>> Dejavau Sans is listed for some fallback coverage of less commonly used
>> unicode blocks.
>>
>> 10646-1 encoding is referenced so as to reduce the number of entries.
>> More UTF 8 locales were added since that is the default on Solaris 11.
>>
>> -phil.
>>
>>

From philip.race at oracle.com  Sat Sep 24 05:00:21 2016
From: philip.race at oracle.com (Philip Race)
Date: Fri, 23 Sep 2016 22:00:21 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <7e65c35c-090e-c6ac-3c42-cc2a45fe66e9@oracle.com>
References: <57D1C59A.20805@oracle.com> <57D1C636.5050601@oracle.com>
	<57E4B8DF.4050704@oracle.com>
	<7e65c35c-090e-c6ac-3c42-cc2a45fe66e9@oracle.com>
Message-ID: <57E60865.9030406@oracle.com>

1) version change is only if the format is incompatible - so no change 
there.
2) paths being absent is not a new issue. It has always been the case that a
file is not present on a system at runtime. This was historically very 
common. The
implementation should handle this.

-phil.

On 9/23/16, 8:17 AM, Sergey Bylokhov wrote:
> The changes looks fine, should we increment version=1 to other version 
> or it is not used? Unrelated question is how we validate all these 
> paths if some of them are absent?
>
> On 23.09.16 8:08, Philip Race wrote:
>> PING .. any takers on this two week old RFR ?
>>
>> -phil.
>>
>> On 9/8/16, 1:12 PM, Philip Race wrote:
>>> [Fix i18n-dev address]
>>>
>>> -phil.
>>>
>>> On 9/8/16, 1:10 PM, Philip Race wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
>>>> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>>>>
>>>> Solaris 10 is not supported by JDK 9.
>>>> This updates the fontconfig file to focus on the default set of fonts
>>>> installed on Solaris 11 as part its desktop.
>>>>
>>>> Preference is given to the Arial, Times New Roman, and Courier New 
>>>> fonts
>>>> that are included with Solaris, as well as other monotype fonts.
>>>> Dejavau Sans is listed for some fallback coverage of less commonly 
>>>> used
>>>> unicode blocks.
>>>>
>>>> 10646-1 encoding is referenced so as to reduce the number of entries.
>>>> More UTF 8 locales were added since that is the default on Solaris 11.
>>>>
>>>> -phil.
>>>>
>>>>
>
>

From masayoshi.okutsu at oracle.com  Sun Sep 25 01:42:13 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sun, 25 Sep 2016 10:42:13 +0900
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <57E60865.9030406@oracle.com>
References: <57D1C59A.20805@oracle.com> <57D1C636.5050601@oracle.com>
	<57E4B8DF.4050704@oracle.com>
	<7e65c35c-090e-c6ac-3c42-cc2a45fe66e9@oracle.com>
	<57E60865.9030406@oracle.com>
Message-ID: <0e7fc837-d037-5922-9f09-b1e523703fc0@oracle.com>

Looks good to me.

Masayoshi


On 9/24/2016 2:00 PM, Philip Race wrote:
> 1) version change is only if the format is incompatible - so no change 
> there.
> 2) paths being absent is not a new issue. It has always been the case 
> that a
> file is not present on a system at runtime. This was historically very 
> common. The
> implementation should handle this.
>
> -phil.
>
> On 9/23/16, 8:17 AM, Sergey Bylokhov wrote:
>> The changes looks fine, should we increment version=1 to other 
>> version or it is not used? Unrelated question is how we validate all 
>> these paths if some of them are absent?
>>
>> On 23.09.16 8:08, Philip Race wrote:
>>> PING .. any takers on this two week old RFR ?
>>>
>>> -phil.
>>>
>>> On 9/8/16, 1:12 PM, Philip Race wrote:
>>>> [Fix i18n-dev address]
>>>>
>>>> -phil.
>>>>
>>>> On 9/8/16, 1:10 PM, Philip Race wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
>>>>> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>>>>>
>>>>> Solaris 10 is not supported by JDK 9.
>>>>> This updates the fontconfig file to focus on the default set of fonts
>>>>> installed on Solaris 11 as part its desktop.
>>>>>
>>>>> Preference is given to the Arial, Times New Roman, and Courier New 
>>>>> fonts
>>>>> that are included with Solaris, as well as other monotype fonts.
>>>>> Dejavau Sans is listed for some fallback coverage of less commonly 
>>>>> used
>>>>> unicode blocks.
>>>>>
>>>>> 10646-1 encoding is referenced so as to reduce the number of entries.
>>>>> More UTF 8 locales were added since that is the default on Solaris 
>>>>> 11.
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>
>>


From Sergey.Bylokhov at oracle.com  Fri Sep 23 15:17:04 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 18:17:04 +0300
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <57E4B8DF.4050704@oracle.com>
References: <57D1C59A.20805@oracle.com> <57D1C636.5050601@oracle.com>
	<57E4B8DF.4050704@oracle.com>
Message-ID: <7e65c35c-090e-c6ac-3c42-cc2a45fe66e9@oracle.com>

The changes looks fine, should we increment version=1 to other version 
or it is not used? Unrelated question is how we validate all these paths 
if some of them are absent?

On 23.09.16 8:08, Philip Race wrote:
> PING .. any takers on this two week old RFR ?
>
> -phil.
>
> On 9/8/16, 1:12 PM, Philip Race wrote:
>> [Fix i18n-dev address]
>>
>> -phil.
>>
>> On 9/8/16, 1:10 PM, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
>>> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>>>
>>> Solaris 10 is not supported by JDK 9.
>>> This updates the fontconfig file to focus on the default set of fonts
>>> installed on Solaris 11 as part its desktop.
>>>
>>> Preference is given to the Arial, Times New Roman, and Courier New fonts
>>> that are included with Solaris, as well as other monotype fonts.
>>> Dejavau Sans is listed for some fallback coverage of less commonly used
>>> unicode blocks.
>>>
>>> 10646-1 encoding is referenced so as to reduce the number of entries.
>>> More UTF 8 locales were added since that is the default on Solaris 11.
>>>
>>> -phil.
>>>
>>>


-- 
Best regards, Sergey.

From vadim.pakhnushev at oracle.com  Sat Sep 24 10:59:29 2016
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Sat, 24 Sep 2016 13:59:29 +0300
Subject: <i18n dev> [OpenJDK 2D-Dev] RFR:
 8162531solaris.fontconfig.properties needs updating
In-Reply-To: <57E60865.9030406@oracle.com>
References: <57D1C59A.20805@oracle.com> <57D1C636.5050601@oracle.com>
	<57E4B8DF.4050704@oracle.com>
	<7e65c35c-090e-c6ac-3c42-cc2a45fe66e9@oracle.com>
	<57E60865.9030406@oracle.com>
Message-ID: <1ab30885-3d9b-3d09-a07b-c919c91d5c76@oracle.com>

+1

Vadim

On 24.09.2016 8:00, Philip Race wrote:
> 1) version change is only if the format is incompatible - so no change 
> there.
> 2) paths being absent is not a new issue. It has always been the case 
> that a
> file is not present on a system at runtime. This was historically very 
> common. The
> implementation should handle this.
>
> -phil.
>
> On 9/23/16, 8:17 AM, Sergey Bylokhov wrote:
>> The changes looks fine, should we increment version=1 to other 
>> version or it is not used? Unrelated question is how we validate all 
>> these paths if some of them are absent?
>>
>> On 23.09.16 8:08, Philip Race wrote:
>>> PING .. any takers on this two week old RFR ?
>>>
>>> -phil.
>>>
>>> On 9/8/16, 1:12 PM, Philip Race wrote:
>>>> [Fix i18n-dev address]
>>>>
>>>> -phil.
>>>>
>>>> On 9/8/16, 1:10 PM, Philip Race wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
>>>>> Webrev: http://cr.openjdk.java.net/~prr/8162531/
>>>>>
>>>>> Solaris 10 is not supported by JDK 9.
>>>>> This updates the fontconfig file to focus on the default set of fonts
>>>>> installed on Solaris 11 as part its desktop.
>>>>>
>>>>> Preference is given to the Arial, Times New Roman, and Courier New 
>>>>> fonts
>>>>> that are included with Solaris, as well as other monotype fonts.
>>>>> Dejavau Sans is listed for some fallback coverage of less commonly 
>>>>> used
>>>>> unicode blocks.
>>>>>
>>>>> 10646-1 encoding is referenced so as to reduce the number of entries.
>>>>> More UTF 8 locales were added since that is the default on Solaris 
>>>>> 11.
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>
>>


From rachna.goel at oracle.com  Wed Sep 28 08:13:57 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 28 Sep 2016 13:43:57 +0530
Subject: <i18n dev> RFR:JDK-8146750:java.time.Month.getDisplayName() return
 incorrect narrow names with JRE provider.
Message-ID: <a4aec435-2840-af25-4b83-73a8209fd1c6@oracle.com>

Hi,

Please review fix for JDK-8146750.

Bug : https://bugs.openjdk.java.net/browse/JDK-8146750

webrev : http://cr.openjdk.java.net/~rgoel/JDK-8146750/webrev.03/

Fix is to retrieve Narrow and Narrow_Standalone Month names as well as 
Day names one by one, as they can be duplicate.

Thanks,

Rachna


From masayoshi.okutsu at oracle.com  Thu Sep 29 14:01:58 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 29 Sep 2016 23:01:58 +0900
Subject: <i18n dev> RFR:JDK-8146750:java.time.Month.getDisplayName()
 return incorrect narrow names with JRE provider.
In-Reply-To: <a4aec435-2840-af25-4b83-73a8209fd1c6@oracle.com>
References: <a4aec435-2840-af25-4b83-73a8209fd1c6@oracle.com>
Message-ID: <5b85d463-8627-6a33-862b-4f2b5036c091@oracle.com>

Hi Rachna,

Sorry, but I've somehow overlooked this fix as java.time changes. The 
test needs to be written for java.time.

Thanks,
Masayoshi


On 9/28/2016 5:13 PM, Rachna Goel wrote:
> Hi,
>
> Please review fix for JDK-8146750.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8146750
>
> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8146750/webrev.03/
>
> Fix is to retrieve Narrow and Narrow_Standalone Month names as well as 
> Day names one by one, as they can be duplicate.
>
> Thanks,
>
> Rachna
>


From martinrb at google.com  Fri Sep 30 19:11:14 2016
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 30 Sep 2016 12:11:14 -0700
Subject: <i18n dev> RFR: 8166983: Remove old/legacy unused tzdata files
Message-ID: <CA+kOe0_5-R_hfjn-15Y86QMabBhHN_aKkK5xRb7TVo4+7YA5Gw@mail.gmail.com>

I have no idea what I'm doing - feel free to take ownership.
https://bugs.openjdk.java.net/browse/JDK-8166983