Don't call av_fetch() with TRUE to create an SV that is immediately freed.

In Perl_my_pclose() the code as been calling av_fetch() with TRUE (lvalue;
create the SV if not found) since the Perl 4 -> Perl 5 migration. The
code *had* been assuming that the returned result was always a valid SvIV
until commit 25d9202327791097 in Jan 2001:
    Safe fix for Simon's pclose() doing SvIVX of undef -> core bug.

which fixes the bug reported in
https://www.nntp.perl.org/group/perl.perl5.porters/2001/01/msg28651.html

That commit changed the code to default the IV result (the pid) to -1 if the
av_fetch() failed to return SVt_IV. However, that commit failed to notice
that the value -1 was *already* "in use" *only 4 lines later* as a flag for
OS/2 to indicate "Opened by popen."

Hence switch the OS/2 sentinel value to -2.

The that states that OS/2 has a my_pclose implementation in os2.c is wrong.
It was erroneously added by commit 5f05dabc4054964a in Dec 1996:
    [inseparable changes from patch from perl5.003_11 to perl5.003_12]

It appears to be a copy-paste error from the previous comment added about
my_popen.

I tested this fix with the 2001-era code of commit 25d9202327791097 - it
(also) solves the bug reported back then.

1 files changed, 1 insertions, 1 deletions

diff --git a/os2/os2.c b/os2/os2.c
index 7c4b6dd7da..0d29d13251 100644
--- a/os2/os2.c
+++ b/os2/os2.c
@@ -1666,7 +1666,7 @@ my_syspopen4(pTHX_ char *cmd, char *mode, I32 cnt, SV** args)
 #  endif 
     sv = *av_fetch(PL_fdpid, PerlIO_fileno(res), TRUE);
     (void)SvUPGRADE(sv,SVt_IV);
-    SvIVX(sv) = -1;			/* A cooky. */
+    SvIVX(sv) = -2;                     /* A cooky. */
     return res;
 
 #endif /* USE_POPEN */