Andrew John Hughes wrote:
2009/12/9 Joseph D. Darcy <joe.da...@sun.com>:
Andrew John Hughes wrote:
2009/12/8 Andrew John Hughes <gnu_and...@member.fsf.org>:

2009/12/8 Joseph D. Darcy <joe.da...@sun.com>:


[snip]


No sooner did I write that than it built:

http://cr.openjdk.java.net/~andrew/tz/webrev.01/

Approved.

The remaining three tz fixes are:

changeset:   639:67c41d740e6d
user:        peytoia
date:        Mon Sep 08 15:21:55 2008 +0900
summary:     6466476: (tz) Introduction of tzdata2005r can introduce
incompatility issues with some JDK1.1 3-letter TZ Ids
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d

changeset:   1693:92b6482e7719
user:        peytoia
date:        Mon Aug 31 14:53:05 2009 +0900
summary:     6456628: (tz) Default timezone is incorrectly set
occasionally on Linux
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719


These other backports approved.

and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID.

Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this
change.

Thanks,

-Joe


Thanks. All of them are now in OpenJDK6.

There is one more backport lurking in IcedTea6:

http://cr.openjdk.java.net/~andrew/tz/webrev.03/

The actual code fix went in to OpenJDK7 in the black hole between the
two (b22): 
http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html
 There should be a bug ID as a result -- presumably, you can discover
that internally?

Donning my fedora and brandishing a bullwhip, the bug id for this change was 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff:

------- TimeZone.java -------
606,610c606
<       if (hasPermission()) {
<           defaultTimeZone = tz;
<       } else {
<           defaultZoneTL.set(tz);
<       }
---
>       defaultTimeZone = tz;
640a637
>               defaultZoneTL.set(null);

There was another file involved in this change, windows/native/java/util/TimeZone_md.c:

------- TimeZone_md.c -------
199a200
>         bufSize = sizeof(val);
347c348
<     valueSize = MAX_ZONE_CHAR;
---
>     valueSize = MAX_MAPID_LENGTH;

This is also the current difference between the OpenJDK 6 and JDK 7 versions of this file.

The test case included in the webrev is from Mark Wielaard and is
contributed through Red Hat's SCA.

There appears to be some test coverage of this change in still-closed regression tests.

CCing i18n-dev in case they have any input; it would be nice to have
the test case in 7 too as well as the fix.

I'll approve this change going back if the change from the JDK 7 version of TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if the @bug line in the test includes 6584033.

Thanks,

-Joe

Reply via email to