On 2016-07-07 18:08, Volker Simonis wrote:
Not sure how error checking could or should be improved:
>VersionProps.parseVersionNumbers(String) will throw a NFE on most malformed
>data, technically an IllegalArgumentException. Same thing would happen if
>you ran an invalid string through Runtime.Version.parse(String) (having
>NumberFormatException specified to be thrown there is perhaps redundant).
>So, wouldn't pre-8160000 behavior be more or less the same if someone
>specified an un-parseable version string during setup?
>
>Perhaps the test could verify that both parseVersionNumber(String) and
>Runtime.Version.parse(String) throws exceptions on the same input.
>
The problem is that they actually don't do that.
parseVersionNumber(String) happily accepts leading zeros or negative
numbers (actually everything that's parsed by Integer.parseInt()).
Handling all these cases in parseVersionNumber(String) would either
make the implementation quite complicated or bring us back to using a
regexp.
You're right, those specific corner-cases would slip through the
8160000 implementation but not Version.parse, but is handled OK by the
build system by virtue of leading zeroes being stripped from and
negative numbers being refused by --with-version-[major|minor|...]
--with-version-string is checking for negative numbers, but doesn't
strip leading zeroes: ---with-version-string=00032.0024 gives exactly
that, which I guess is an issue.
I guess a follow-up RFE to plug that hole in the build and perhaps to
write a regression test verifying that configure doesn't accept badly
formed version strings is in order.
/Claes
