From 64903a26c5855347738825d7724e76e8a89180f3 Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Fri, 7 Jul 2017 11:11:33 +0200 Subject: [PATCH] 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 (Merged from https://github.com/openssl/openssl/pull/3880) (cherry picked from commit 4549ed12ec3337313c14815438fa9aee88bf1359) --- test/run_tests.pl | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) 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. } -- 2.25.1