The change looks fine. Thanks Max
> On Jan 25, 2018, at 1:52 PM, sha.ji...@oracle.com wrote: > > Hi Max, Xuelei, > Please review this updated patch: > http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/ > Both of your suggestions are addressed. > > Best regards, > John Jiang > > On 24/01/2018 12:20, Weijun Wang wrote: >> >>> On Jan 24, 2018, at 11:28 AM, sha.ji...@oracle.com wrote: >>> >>> Hi Max, >>> >>> On 23/01/2018 17:49, Weijun Wang wrote: >>>> Can you show us why the new code works? >>> The test assumes that nss3 lib contains a string likes: >>> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" >>> or >>> Version: NSS version.number, e.g. "Version: NSS 3.34.1" >>> >>> But the current test expects that the version.number is followed by a space >>> immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to >>> locate the next space index for parsing the version. >>> Unfortunately, that assumption is not true on some NSS builds. For example, >>> "Version: NSS 3.34.1 �". >> I see. >> >> BTW, the byte-to-string conversion looks a little strange as the data is >> pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe. >> >> --Max >> >>> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " >>> or "Version: NSS ". If a char, which is not in the specific char set ("." >>> or "0-9"), is met, that means the version has been extracted. >>> >>>> What does "s" looks like? >>> The followings are some snippets of nss3 lib from different NSS builds. >>> 1. NSS 3.16.2 on macosx >>> Content-Length: %u >> >
