Thanks Claes!
webrev has been updated accordingly
http://cr.openjdk.java.net/~sherman/8173072/webrev
On 01/19/2017 03:04 PM, Claes Redestad wrote:
Looks good to me.
You could simplify a bit and write: int end = locPos + locSZ - 4;
and use direct comparisons instead of adding 4 in each test.
Thanks!
/Claes
On 2017-01-19 22:39, Xueming Shen wrote:
Hi
Please review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8173072
webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
As described in the issue, the root cause is that the offending zip/jar
file
has a "extended timestamp extra field" that does not strictly follow the
spec, AND the zipfs implementation does not do a good job to do sanity
check on the data size like what the ZipEntry code does when check the
timestamps. The change here is to check both the flag and the length,
stop reading a/ctime if there is no more data, even the flags field says
there are more data.
I have run the test manually to verify the change, but decided not to check
in a binary zip/jar file (which is not encouraged for jdk repo) for the
regression test.
Thanks,
Sherman
