test/run_tests.pl: Make sure to exit with a code that's understood universally

TAP::Parser::Aggregator::has_errors may return any number, not just 0
and 1.  With Perl on VMS, any number from 2 and on is interpreted as a
VMS status, the 3 lower bits are the encoded severity (1 = SUCCESS,
for example), so depending on what has_errors returns, a test failure
might be interpreted as a success.  Therefore, it's better to make
sure the exit code is 0 or 1, nothing else (they are special on VMS,
and mean SUCCESS or FAILURE, to match Unix conventions).

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3880)

(cherry picked from commit 4549ed12ec3337313c14815438fa9aee88bf1359)

1 files changed, 10 insertions, 1 deletions

diff --git a/test/run_tests.pl b/test/run_tests.pl
index 61fdff6398..e5bc927e67 100644
--- a/test/run_tests.pl
+++ b/test/run_tests.pl
@@ -64,7 +64,16 @@ if ($list_mode) {
     my $harness = $TAP_Harness->new(\%tapargs);
     my $ret = $harness->runtests(sort @tests);
 
-    exit $ret->has_errors if (ref($ret) eq "TAP::Parser::Aggregator");
+    # $ret->has_errors may be any number, not just 0 or 1.  On VMS, numbers
+    # from 2 and on are used as is as VMS statuses, which has severity encoded
+    # in the lower 3 bits.  0 and 1, on the other hand, generate SUCCESS and
+    # FAILURE, so for currect reporting on all platforms, we make sure the only
+    # exit codes are 0 and 1.  Double-bang is the trick to do so.
+    exit !!$ret->has_errors if (ref($ret) eq "TAP::Parser::Aggregator");
+
+    # If this isn't a TAP::Parser::Aggregator, it's the pre-TAP test harness,
+    # which simply dies at the end if any test failed, so we don't need to
+    # bother with any exit code in that case.
 }