| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test from t/op/gv.t was added by change 22315/4ce457a6:
{
# test the assignment of a GLOB to an LVALUE
my $e = '';
local $SIG{__DIE__} = sub { $e = $_[0] };
my $v;
sub f { $_[0] = 0; $_[0] = "a"; $_[0] = *DATA }
f($v);
is ($v, '*main::DATA');
my $x = <$v>;
is ($x, "perl\n");
}
That change was the one that made glob-to-lvalue assignment work to
begin with. But this test passes in perl version *prior* to that
change.
This patch fixes the test and adds tests to make sure what is assigned
is actually a glob, and not just a string.
It also happens to fix the stringification bug. In doing so, it essen-
tially ‘enables’ globs-as-PVLVs.
It turns out that many different parts of the perl source don’t fully
take this into account, so this patch also fixes the following to work
with them (I tried to make these into separate patches, but they are
so intertwined it just got too complicated):
• GvIO(gv) to make readline and other I/O ops work.
• Autovivification of glob slots.
• tie *$pvlv
• *$pvlv = undef, *$pvlv = $number, *$pvlv = $ref
• Duplicating a filehandle accessed through a PVLV glob when the
stringified form of the glob cannot be used to access the file
handle (!)
• Using a PVLV glob as a subroutine reference
• Coderef assignment when the glob is no longer in the symbol table
• open with a PVLV glob for the filehandle
• -t and -T
• Unopened file handle warnings
|
| |
|
| |
|
|
|
|
|
| |
This better represents its current role as specifically delaying magic on
@ISA as opposed to a general array magic delay mechanism.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The "short" names become macro wrappers, and the Perl_* versions become mathoms.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
away const, returning a void *. Add MUTABLE_SV(sv) which uses this, and
replace all (SV *) casts either with MUTABLE_SV(sv), or (const SV *).
This probably still needs some work - assigning to SvPVX() and SvRV()
is now likely to generate a casting error. The core doesn't do this.
But as-is it's finding bugs that can be fixed.
p4raw-id: //depot/perl@34605
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
|
| |
From: "Reini Urban" <rurban@x-ray.at>
Message-ID: <6910a60806080541n4f7e1939q254797411545ebea@mail.gmail.com>
p4raw-id: //depot/perl@34029
|
|
|
|
|
|
|
|
|
|
|
| |
gv_fetchmethod. It therefore needs to duplicate a lot of
the internals of that function.
"Duplicate". <snigger>. You said a naughty word. Now sanitised.
[All tests pass, but I'm not 100% confident that this code is
equivalent in all reachable corner cases, and it may be possible
to simplify the error reporting logic now in gv_fetchmethod_flags]
p4raw-id: //depot/perl@33702
|
|
|
|
|
| |
Nullhek and Nullhv. Nullop is going to be a bit less simple.
p4raw-id: //depot/perl@33051
|
|
|
| |
p4raw-id: //depot/perl@32237
|
|
|
|
|
|
| |
From: "Brandon Black" <blblack@gmail.com>
Message-ID: <84621a60708121336m13dcf9e5uac624fb246f2a79c@mail.gmail.com>
p4raw-id: //depot/perl@31770
|
|
|
| |
p4raw-id: //depot/perl@31396
|
|
|
|
|
|
| |
platforms. On LP64 structs stackinfo, refcounted_he, and magic shrink
by 8 bytes, struct yy_parser by 16.
p4raw-id: //depot/perl@30817
|
|
|
|
|
| |
the GV's name can be NULL.
p4raw-id: //depot/perl@30439
|
|
|
|
|
| |
allows symbolic code references with embeded NULs to work.
p4raw-id: //depot/perl@29830
|
|
|
| |
p4raw-id: //depot/perl@29536
|
|
|
|
|
| |
bad thing.
p4raw-id: //depot/perl@28067
|
|
|
|
|
|
|
| |
COPs created by use can be freed along this memory, but the GP
remains. Given that several GVs may refer to the same file, use a
shared string rather than an individual allocation per GP.
p4raw-id: //depot/perl@28060
|
|
|
|
|
| |
Message-ID: <20060424184451.GA1479@petdance.com>
p4raw-id: //depot/perl@27958
|
|
|
|
|
|
|
| |
First patch from :
Subject: Re: [PATCH] cleanup 212 warnings emitted by gcc-4.2
Message-ID: <20060423044704.6a383ee8@r2d2>
p4raw-id: //depot/perl@27944
|
|
|
|
|
| |
Message-ID: <20060331054228.GA18940@petdance.com>
p4raw-id: //depot/perl@27641
|
|
|
|
|
| |
non-gcc-debugging ifdef. Whoops. Very lax of me)
p4raw-id: //depot/perl@27383
|
|
|
|
|
| |
to simplify GV initialisation.
p4raw-id: //depot/perl@27382
|
|
|
|
|
| |
smaller.
p4raw-id: //depot/perl@27380
|
|
|
|
|
|
|
| |
Saves 1 word in each GV (no more strlen), and will also save the memory
used by the string itself, as the HEK will exist already due to the
key used by the symbol table for this GV.
p4raw-id: //depot/perl@27379
|
|
|
| |
p4raw-id: //depot/perl@27377
|
|
|
|
|
| |
Message-ID: <20060226025216.GA12758@petdance.com>
p4raw-id: //depot/perl@27344
|
|
|
| |
p4raw-id: //depot/perl@27331
|
|
|
| |
p4raw-id: //depot/perl@27330
|
|
|
|
|
| |
Assert that GVs do not access SvCUR or SvLEN.
p4raw-id: //depot/perl@27328
|
|
|
|
|
|
| |
both sides of an assignment using GvASSIGN_GENERATION() and
GvASSIGN_GENERATION_set().
p4raw-id: //depot/perl@27327
|
|
|
|
|
| |
PVGVs by another pointer.
p4raw-id: //depot/perl@27326
|
|
|
|
|
| |
accessed unless the GV thinks that it is a GV.
p4raw-id: //depot/perl@27324
|
|
|
|
|
|
|
|
| |
this avoids 1 pointer dereference and the associated risk of a CPU
cache miss. Although this patch looks deceptively small, I fear its
CBV(*) might be rather high.
(* Crack By Volume)
p4raw-id: //depot/perl@27323
|
|
|
| |
p4raw-id: //depot/perl@27307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MinGW problem described here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00146.html
was fixed by change #26664. This is no longer relevant in the light of
change #27152, so revert it.
(The other problems with VC++ 6 and BCC, fixed by change #26634, have
not gone away, however.)
p4raw-link: @27152 on //depot/perl: b0e6ae5b51a7c163ac7cdb0d18b54bb1819f6c13
p4raw-link: @26664 on //depot/perl: fb9e8e97420770e8f89d9f2196e1b7b0c855e8bb
p4raw-link: @26634 on //depot/perl: 834268b87a8eb670d899a13106c8dfcdfc7c9b66
p4raw-id: //depot/perl@27171
|
|
|
|
|
|
| |
Message-ID: <20060202150241.GF12591@accognoscere.homeunix.org>
Date: Thu, 2 Feb 2006 16:02:41 +0100
p4raw-id: //depot/perl@27060
|
|
|
|
|
|
|
| |
loop is iterated over millions of times. Add a flag GV_NOTQUAL purely
as an optimisation, when the caller is passing in a string that is
known not to contain any package separators.
p4raw-id: //depot/perl@27053
|
|
|
|
|
| |
MinGW doesn't like 26395 either! (ref: change 26634)
p4raw-id: //depot/perl@26664
|
|
|
| |
p4raw-id: //depot/perl@26652
|
|
|
|
|
|
|
|
| |
Can't understand what VC++ 6 and Borland don't like about it. There
is similar code for SvMAGIC and SvSTASH already in sv.h. Must be
compiler bugs since VC++ 7 and MinGW (and compilers on other platforms)
are all happy.
p4raw-id: //depot/perl@26634
|
|
|
|
|
|
|
| |
as proxy constant subroutines in a new symbol table where possible.
(Rather than converting them to full blown constant subroutines and
instantiating 2 typeglobs)
p4raw-id: //depot/perl@26446
|
|
|
|
|
|
|
| |
addition of new typeglobs, and also disables initialisation of any
typeglob placeholders. Needed to make the new constant subroutine
proxy references work efficiently.
p4raw-id: //depot/perl@26425
|