> 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
