The test for #76474 should open file descriptor 0, not 1.

The original bug report states

    if we try to dup STDIN in a child process by using it's file descriptor

but has code to dup 1, not 0:

    perl -MIPC::Open3 -wle 'open3("<&1", my $out, undef, $^X)'

Change the above code to "<&0" and the same bug is demonstrated, and fixed by
the relevant change.

However, trying to open descriptor 1 for input causes subtle portability
problems, which conceal the actual bug we're attempting to test. On most
platforms the terminal is read write, and a command tested on the command line
actually has file descriptor 1 read/write (and probably file descriptor 0 also)

When the output is being piped, for example in a test checking the output,
descriptor 1 is (likely to be) write only. PerlIO is quite happy to *open* a
such a numeric file descriptor for reading, and will only generate an error if
an actual read is attempted (which this test does not). stdio (on several
platforms tested) fails the *open* in the same scenario. Hence whether this
*test* passed or failed depended on the IO system used, which is actually not
what we want to test.

Original test added in a0ed8b7b5f7f6d6f, fix added in fb9b5b31d8a62644.

diff --git a/ext/IPC-Open3/t/fd.t b/ext/IPC-Open3/t/fd.t
index 354ebd1..4e27427 100644 (file)
--- a/ext/IPC-Open3/t/fd.t
+++ b/ext/IPC-Open3/t/fd.t
@@ -1,10 +1,6 @@
 #!./perl
 
 BEGIN {
-    if (!PerlIO::Layer->find('perlio') || $ENV{PERLIO} eq 'stdio') {
-       print "1..0 # Skip: not perlio\n";
-       exit 0;
-    }
     if ($^O eq 'VMS') {
         print "1..0 # Skip: needs porting, perhaps imitating Win32 mechanisms\n";
        exit 0;
@@ -20,7 +16,7 @@ plan 3;
 {
   my $stderr = runperl(
      switches => ['-MIPC::Open3', '-w'],
-     prog => 'open STDIN, q _Makefile_ or die $!; open3(q _<&1_, my $out, undef, $ENV{PERLEXE}, q _-e0_)',
+     prog => 'open STDIN, q _Makefile_ or die $!; open3(q _<&0_, my $out, undef, $ENV{PERLEXE}, q _-e0_)',
      stderr => 1,
   );