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
