Commit 64903a26 authored by Richard Levitte's avatar Richard Levitte
Browse files

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: default avatarTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3880)

(cherry picked from commit 4549ed12)
parent e9c17ef9

test/run_tests.pl

+10 −1
Original line number Diff line number Diff line
@@ -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.

}