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

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.