PL_defoutgv isn't always a GV.
authorDavid Mitchell <davem@iabyn.com>
Tue, 30 Mar 2010 14:03:50 +0000 (15:03 +0100)
committerDavid Mitchell <davem@iabyn.com>
Tue, 30 Mar 2010 14:03:50 +0000 (15:03 +0100)
commit099be4f1d597471eb719c9a344b7c1b55e11ba24
tree46ddeb749d35c52c3df9d34f54e7200aef8ddbcf
parent447ee1343739cf8e34c4ff1ba9b30eae75c3f1ab
PL_defoutgv isn't always a GV.

Nasty code like the following results in PL_defoutgv not pointing
to a valid GV:

    my $x = *STDERR; select($x); $x = 1;

This causes all sorts of SEGVs when PL_defoutgv is subsequently accessed,
because most code assumes that it has a valid gv_gp pointer.  It also
turns out that PL_defoutgv is under-tested; for example, temporarily
hacking pp_close to make an arg-less close() croak didn't cause any
minitest failures.

Add a new test file that does some basic testing of a bad PL_defoutgv,
and fix all the obvious badness in accessing it.

This also fixes #20727, which although ostensibly a tie bug, was due to
PL_defoutgv pointing to a tiedelem scalar, and fun like that described
above happening.
MANIFEST
gv.c
gv.h
mg.c
pp_hot.c
pp_sys.c
t/io/defout.t [new file with mode: 0644]
t/op/tie.t