| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT
or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference.
(g++ does not do the "post-annotation" form of "unused".)
The version code has some of these issues, reported upstream.
|
|
|
|
| |
I think I have incorporated everybody's concerns in this patch.
|
|
|
|
|
|
|
|
| |
Some bad code generation/bad optimization from VC caused me to clean this
up. Dont write AvARRAY(av)[key] = NULL twice. It appears in 2 branches
just as written VC asm wise. Don't call sv_2mortal on a NULL SV*. It
works but less efficient. On VC2008 x64 -O1 this func dropped from 0x208
to 0x202 bytes of machine code after this patch.
|
|
|
|
| |
plus some typo fixes. I probably changed some things in perlintern, too.
|
|
|
|
|
|
| |
This allows us easily to catch cases where the stack could move to a
new memory address while code still holds pointers to the old loca-
tion. Indeed, this causes test failures.
|
|
|
|
|
| |
This fixes a Win32 Visual C 6 in C++ mode syntax error. See #120544 for
the details.
|
|
|
|
|
|
|
|
|
|
|
| |
$tied[-1] = crash
This code in av.c, when trying to find $NEGATIVE_INDICES, was doing a
direct stash element lookup--instead of going through the normal GV
functions--and then expecting the returned value to be a GV.
‘sub NEGATIVE_INDICES’ creates a stash element that is a PV, not a GV,
so it’s easy to make things crash.
|
|
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I am referring to what is usually known simply as The Stack.)
This partially fixes #119161.
By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all. Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.
I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes bug #7508 and provides the groundwork for fixing
several other bugs.
Elements of @_ are aliased to the arguments, so that \$_[0] within
sub foo will reference the same scalar as \$x if the sub is called
as foo($x).
&PL_sv_undef (the global read-only undef scalar returned by the
‘undef’ operator itself) was being used to represent nonexistent
array elements. So the pattern would be broken for foo(undef), where
\$_[0] would vivify a new $_[0] element, treating it as having been
nonexistent.
This also causes other problems with constants under ithreads
(#105906) and causes a pending fix for another bug (#118691) to trig-
ger this bug.
This commit changes the internals to use a null pointer to represent a
nonexistent element.
This requires that Storable be changed to account for it. Also,
IPC::Open3 was relying on the bug. So this commit patches
both modules.
|
| |
|
|
|
|
|
|
| |
Perl_magic_methcall is not public API, so there is no
need to add another function and we can just change
function's arguments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
STRANGE_MALLOC was added in 5.002 beta 1 (4633a7c4bad06b47) as part of an
work around for typical mallocs, which had a bad interaction with perl's
allocation needs. Specifically, repeatedly extending an array and then
creating SV heads (such as when reading lines of a file into an array)
could end up with each reallocation for the array being unable to extend in
place, needing a fresh chunk of memory, and the released memory not being
suitable for use as more SV heads, so sitting unused. The solution was for
perl to recycle the old array body as SV heads, instead of returning it to
the system, passing the memory from the the AV code to the SV code using
offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size.
STRANGE_MALLOC was actually a signal that the malloc() didn't need
protecting from itself, and to disable the work around.
offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size were removed by
commit 9a87bd09eea1d037 in Nov 2010, without any ill effects, hence the
code used when STRANGE_MALLOC was *not* defined is essentially doing extra
work for no benefits.
From the lack of problems reported, one can assume that in the intervening
15 years malloc technology has got significantly improved, and it is probably
better to be honest with it, rather than trying to second guess it.
Hence remove all the non-STRANGE_MALLOC code, and leave everyone using the
much simpler code. See also
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-11/msg00495.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-01/msg00126.html
|
|
|
|
|
| |
The latter is a somewhat less clumsy name. The old one is provided a a
very clear name; the new one as a somewhat slangy version
|
|
|
|
|
| |
This function is just an assert and a macro call. Avoid the function
call overhead by making it inline.
|
|
|
|
|
|
|
|
| |
In using the av_top() function created in a recent commit, I found
myself being confused, and thinking it meant the top element of the
array, whereas it really means the index of the top element of that
array. Since the new name has not appeared in a stable release, it can
be changed, without remorse, to include 'index' in it.
|
|
|
|
|
| |
These were all uncovered by the new Pod::Checker, not yet in core.
Fixing these will speed up debugging the new Checker.
|
|
|
|
| |
av_len() is misleadingly named.
|
|
|
|
|
|
|
| |
This notes that the caller now has control of a reference count of the
returned SV.
Wording mostly suggested by Paul Evans
|
|
|
|
|
|
|
| |
This finishes the removal of register declarations started by
eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in
function parameter declarations, and didn't include things in dist, ext,
and lib, which this does include
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make av_exists slightly smaller and faster by reducing the liveness of a
mortal SV and using a NN SvTRUE_nomg.
There were 3 cases, where this mortal would be created, yet a return
happened and the mortal went unused and was wasted. So move the mortal
creation point closer to where it is first used. Also var sv will never be
null, so use a NN version of SvTRUE_nomg created in commit [perl #115870].
The retbool line isn't actually required for optimization reasons, but was
created just in case something in the future changes or some unknown
compiler does something inefficiently.
For me with 32 bit x86 VC 2003, before av_exists was 0x1C2, after 0x1B8.
Comment from committer: Includes SvTRUE_nomg_NN from [perl #115870].
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the context/pTHX from Perl_croak_no_modify and Perl_croak_xs_usage.
For croak_no_modify, it now has no parameters (and always has been
no return), and on some compilers will now be optimized to a conditional
jump. For Perl_croak_xs_usage one push asm opcode is removed at the caller.
For both funcs, their footprint in their callers (which probably are hot
code) is smaller, which means a tiny bit more room in the cache. My text
section went from 0xC1A2F to 0xC198F after apply this. Also see
http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195233.html .
|
|
|
|
|
| |
The code for checking to see whether $NEGATIVE_INDICES is defined in
the tie package was very fragile, and was repeated four times.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was broken in 5.14.0 for those cases where $NEGATIVE_INDICES is
not true:
sub TIEARRAY{bless[]};
sub FETCHSIZE { 50 }
sub EXISTS { print "does $_[1] exist?\n" }
tie @a, "";
exists $a[1];
exists $a[-1];
$NEGATIVE_INDICES=1;
exists $a[-1];
$ pbpaste|perl5.12.0
does 1 exist?
does 49 exist?
does -1 exist?
$ pbpaste|perl5.14.0
does 1 exist?
does -1 exist?
This was broken by 54a4274e3c.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various pieces of code were creating an SV and then assigning to it
from a value that might be magical. If the source scalar is magical,
it could die when magic is called, leaking the scalar that would have
been assigned to.
So we call get-magic before creating the new scalar, and then use a
non-magical assignment.
Also, anonhash and anonlist were doing nothing to protect the aggre-
gate if an argument should die on FETCH, resulting in a leak.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to fix a bug, I need to add new fields to padlists. But I
cannot easily do that as long as they are AVs.
So I have created a new padlist struct.
This not only allows me to extend the padlist struct with new members
as necessary, but also saves memory, as we now have a three-pointer
struct where before we had a whole SV head (3-4 pointers) + XPVAV (5
pointers).
This will unfortunately break half of CPAN, but the pad API docs
clearly say this:
NOTE: this function is experimental and may change or be
removed without notice.
This would have broken B::Debug, but a patch sent upstream has already
been integrated into blead with commit 9d2d23d981.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In restore_magic(), which is called after any magic processing, all of
the public OK flags have been shifted into the private OK flags. Thus
the lack of an appropriate public OK flags was used to trigger both get
magic and required conversions. This scheme did not cover ROK, however,
so all properly written code had to make sure mg_get was called the right
number of times anyway. Meanwhile the private OK flags gained a second
purpose of marking converted but non-authoritative values (e.g. the IV
conversion of an NV), and the inadequate flag shift mechanic broke this
in some cases.
This patch removes the shift mechanic for magic flags, thus exposing (and
fixing) some improper usage of magic SVs in which mg_get() was not called
correctly. It also has the side effect of making magic get functions
specifically set their SVs to undef if that is desired, as the new behavior
of empty get functions is to leave the value unchanged. This is a feature,
as now get magic that does not modify its value, e.g. tainting, does not
have to be special cased.
The changes to cpan/ here are only temporary, for development only, to
keep blead working until upstream applies them (or something like them).
Thanks to Rik and Father C for review input.
|
|
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make the code slightly smaller by changing
if (A)
return X;
if (B)
return X;
into
`
if (A || B)
return X;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> > Actually, the simplest solution seem to be to put the av or hv on
> > the mortals stack in pp_aassign and pp_undef, rather than in
> > [ah]v_undef/clear.
>
> This makes me nervous. The tmps stack is typically cleared only on
> statement boundaries, so we run the risks of
>
> * user-visible delaying of freeing elements;
> * large tmps stack growth might be possible with
> certain types of loop that repeatedly assign to an array without
> freeing tmps (eg map? I think I fixed most map/grep tmps leakage
> a
> while back, but there may still be some edge cases).
>
> Surely an ENTER/SAVEFREESV/LEAVE inside pp_aassign is just as
> efficient,
> without any attendant risks?
>
> Also, although pp_aassign and pp_undef are now fixed, the
> [ah]v_undef/clear functions aren't, and they're part of the public API
> that can be called independently of pp_aassign etc. Ideally they
> should
> be fixed (so they don't crash in mid-loop), and their documentation
> updated to point out that on return, their AV/HV arg may have been
> freed.
This commit takes care of the first part; it changes pp_aassign to use
ENTER/SAVEFREESV/LEAVE and adds the same to h_freeentries (called both
by hv_undef and hv_clear), av_undef and av_clear.
It effectively reverts the C code part of 9f71cfe6ef2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Tue Mar 08 07:26:35 2011, thospel wrote:
> #!/usr/bin/perl -l
> use Data::Dumper;
> use Scalar::Util qw(weaken);
> our @ISA;
>
> for (1..2) {
> @ISA = qw(Foo);
> weaken($a = \@ISA);
> weaken($a = \$ISA[0]);
> print STDERR Dumper(\@ISA);
> }
>
> This prints:
> $VAR1 = [
> 'Foo'
> ];
> $VAR1 = [
> 'Foo',
> \$VAR1->[0]
> ];
>
> So the first time it's the expected @ISA, but the second time round it
> automagically added a reference to to the first ISA element
>
> (bug also exists in blead)
Shorter:
#!/usr/bin/perl -l
use Scalar::Util qw(weaken);
weaken($a = \@ISA);
@ISA = qw(Foo);
use Devel::Peek; Dump \@ISA;
weaken($a = \$ISA[0]);
print scalar @ISA; # prints 2
The dump shows the problem. backref magic is being copied to the ele-
ment. Put the magic in a different order, and everything is fine:
#!/usr/bin/perl -l
use Scalar::Util qw(weaken);
weaken($a = $b = []);
*ISA = $a;
@ISA = qw(Foo);
use Devel::Peek; Dump \@ISA;
weaken($a = \$ISA[0]);
print scalar @ISA; # prints 2
This code in av_store is so wrong:
if (SvSMAGICAL(av)) {
const MAGIC* const mg = SvMAGIC(av);
if (val != &PL_sv_undef) {
sv_magic(val, MUTABLE_SV(av), toLOWER(mg->mg_type), 0, key);
}
if (PL_delaymagic && mg->mg_type == PERL_MAGIC_isa)
PL_delaymagic |= DM_ARRAY_ISA;
else
mg_set(MUTABLE_SV(av));
}
It doesn’t follow the magic chain at all. So anything magic could get
attached to the @ISA array, and that will be copied to the element
instead of isa magic.
Notice that MUTABLE_SV(av) is the second argument to sv_magic, so
mg->mg_obj for the element always points back to the array.
Since backref magic’s mg->mg_obj points to the backrefs array, @ISA
ends up being used as this element’s backrefs array.
What if arylen_p gets copied instead? Let’s see:
$#ISA = -1;
@ISA = qw(Foo);
$ISA[0] = "Bar";
main->ber;
sub Bar::ber { warn "shave" }
__END__
Can't locate object method "ber" via package "main" at - line 7.
I’ve fixed this by making av_store walk the magic chain, copying any
magic for which toLOWER(mg->mg_type) != mg->mg_type.
|
| |
|
|
|
|
|
| |
This is a patch to enhance perlapi.pod by providing Perl equivalents and
clarifying documentation where appropriate.
|
|
|
|
| |
to fix the generated pod
|
|
|
|
|
| |
Contrary to the previous text, av_store() requires the user to deal with the
reference count of the scalar being added.
|
|
|
|
|
|
|
|
| |
Perl_av_exists tested to see if regdata magic was present,
but did not have any logic to fetch that data in the positive
key case. Additionally, in the negative key case, if AvFILL
indicated the key existed, it wouldn't return, and would then
fall through to the logic that treated it like a real array.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These provided a non-public API for the hash and array code to donate free
memory direct to the SV head allocation routines, instead of returning it
to the malloc system with free().
I assume that on some older mallocs this could offer significant benefits.
However, my benchmarking on a modern malloc couldn't detect any significant
effect (positive or negative) on removing the code. Its (continued) presence,
however, has downsides
a: slightly more code complexity
b: slightly larger interpreter structure
c: in the steady state, if net creation of SVs is zero, 1 chunk of allocated
but unused memory will exist (per thread)
So I think it best to remove it.
|
|
|
|
|
| |
This reduces object code size, reducing CPU cache pressure on the non-exception
paths.
|
|
|
|
|
| |
This better represents its current role as specifically delaying magic on
@ISA as opposed to a general array magic delay mechanism.
|
|
|
|
| |
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
| |
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
|
|
| |
Minor, but still good enough for a commit.
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
|
|
|
|
| |
Thanks to LeoNerd and Zefram on #p5p on IRC for some insights and
suggesting versions for the modified text. I ended up using Zefram's
version.
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
|
|
| |
This mentions that it's equivalent to exists($myarray[$key]).
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
| |
Signed-off-by: David Golden <dagolden@cpan.org>
|
|
|
|
| |
Signed-off-by: David Golden <dagolden@cpan.org>
|