Re: Supporting TAP tests with MSVC and Windows - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Supporting TAP tests with MSVC and Windows
Date
Msg-id 2856ec20-157c-8119-4f4d-fc15e23efe20@dunslane.net
Whole thread Raw
In response to Re: Supporting TAP tests with MSVC and Windows  (Noah Misch <noah@leadboat.com>)
Responses Re: Supporting TAP tests with MSVC and Windows
List pgsql-hackers
On 2022-08-21 Su 20:40, Noah Misch wrote:
> This (commit 13d856e of 2015-07-29) added the following:
>
> --- a/src/test/perl/TestLib.pm
> +++ b/src/test/perl/TestLib.pm
> @@ -242,7 +288,17 @@ sub command_exit_is
>      print("# Running: " . join(" ", @{$cmd}) ."\n");
>      my $h = start $cmd;
>      $h->finish();
> -    is($h->result(0), $expected, $test_name);
> +
> +    # On Windows, the exit status of the process is returned directly as the
> +    # process's exit code, while on Unix, it's returned in the high bits
> +    # of the exit code (see WEXITSTATUS macro in the standard <sys/wait.h>
> +    # header file). IPC::Run's result function always returns exit code >> 8,
> +    # assuming the Unix convention, which will always return 0 on Windows as
> +    # long as the process was not terminated by an exception. To work around
> +    # that, use $h->full_result on Windows instead.
> +    my $result = ($Config{osname} eq "MSWin32") ?
> +        ($h->full_results)[0] : $h->result(0);
> +    is($result, $expected, $test_name);
>  }
>
> That behavior came up again in the context of a newer IPC::Run test case.  I'm
> considering changing the IPC::Run behavior such that the above would have been
> unnecessary.  However, if I do, the above code would want to adapt to handle
> pre-change and post-change IPC::Run versions.  If you have an opinion on
> whether or how IPC::Run should change, I welcome comments on
> https://github.com/toddr/IPC-Run/issues/161.
>
>


Assuming it changes, we'll have to have a version test here. I don't
think we can have a flag day where we suddenly require IPC::Run's
bleeding edge on Windows. So changing it is a good thing, but it won't
help us much.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] ALTER TABLE ... SET STORAGE default
Next
From: Christoph Berg
Date:
Subject: Re: pg_receivewal and SIGTERM