| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
but is failing on Windows. Anyways sv_utf8_upgrade_nomg() is
a macro anyways, so moving the documentation to sv.h.
|
|
|
|
|
|
| |
From: karl williamson <public@khwilliamson.com>
Date: Tue, 16 Dec 2008 16:00:34 -0700
Message-ID: <49483312.80804@khwilliamson.com>
|
|
|
|
|
| |
Message-ID: <20081127070141.GD17663@tytlal.topaz.cx>
p4raw-id: //depot/perl@35018
|
|
|
|
|
| |
SAVEt_DELETE for a space optimisation.
p4raw-id: //depot/perl@34969
|
|
|
| |
p4raw-id: //depot/perl@34967
|
|
|
|
|
| |
This brings it to the same order as save_aelem() or save_pushi32ptr().
p4raw-id: //depot/perl@34964
|
|
|
| |
p4raw-id: //depot/perl@34938
|
|
|
|
|
| |
Message-ID: <20081114084436.GJ5779@tytlal.topaz.cx>
p4raw-id: //depot/perl@34831
|
|
|
|
|
| |
Also add new SvRV_const() macro for read-only access.
p4raw-id: //depot/perl@34804
|
|
|
|
|
|
| |
tests introduced with #34781 pass. Add some more warning
tests to t/lib/warnings/sv.
p4raw-id: //depot/perl@34783
|
|
|
|
|
|
|
| |
Message-Id: <200811081329.mA8DTv7e018896@zen.crypt.org>
Plus some test cases.
p4raw-id: //depot/perl@34780
|
|
|
|
|
|
|
| |
MUTABLE_SV() check. Use SvPVX_const() instead of SvPVX()
where only a const SV* is available. Also fix two falsely
consted pointers in Perl_sv_2pv_flags().
p4raw-id: //depot/perl@34770
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
|
|
|
| |
This is mostly to silence gcc's warning, "format not a string
literal and no format arguments".
p4raw-id: //depot/perl@34694
|
|
|
|
|
|
| |
Can't easily do gv.h, as GvGP() (at least) needs to split into two
macros - one const for reading, one non-const for writing.
p4raw-id: //depot/perl@34679
|
|
|
|
|
| |
const SV *, then so can Perl_report_uninit().
p4raw-id: //depot/perl@34673
|
|
|
|
|
| |
Perl_sv_magicext(), which is documented.
p4raw-id: //depot/perl@34671
|
|
|
| |
p4raw-id: //depot/perl@34654
|
|
|
| |
p4raw-id: //depot/perl@34653
|
|
|
| |
p4raw-id: //depot/perl@34650
|
|
|
| |
p4raw-id: //depot/perl@34647
|
|
|
|
|
| |
its arguments.
p4raw-id: //depot/perl@34646
|
|
|
| |
p4raw-id: //depot/perl@34629
|
|
|
| |
p4raw-id: //depot/perl@34627
|
|
|
|
|
| |
(const HV *).
p4raw-id: //depot/perl@34626
|
|
|
| |
p4raw-id: //depot/perl@34623
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
| |
from 'void *' explicit.
p4raw-id: //depot/perl@34576
|
|
|
|
|
| |
Message-ID: <20081022013731.23b5a2e5@r2d2>
p4raw-id: //depot/perl@34568
|
|
|
|
|
|
|
| |
be reset if its SV is freed. (see change 22688 (30952)).
A real live bug found by Slaven and Andreas whilst smoking maint-5.8.x.
I guess that we should audit the interpreter structure for any others.
p4raw-id: //depot/perl@34479
|
|
|
|
|
| |
The bug turns out to have been introduced in 2003, with change 18580.
p4raw-id: //depot/perl@34371
|
|
|
|
|
| |
This may still be referenced, so don't reuse.
p4raw-id: //depot/perl@34220
|
|
|
|
|
|
|
| |
key scalar from the key of the hash entry we've just creating.
(Currently the hash is disposed of afterwards, but soon it won't, so
having both point to the same string buffer will also save memory.)
p4raw-id: //depot/perl@34215
|
|
|
|
|
| |
unitialised reads (and sometimes even SEGVs).
p4raw-id: //depot/perl@34213
|
|
|
| |
p4raw-id: //depot/perl@34211
|
|
|
|
|
|
|
|
|
|
|
| |
In several places where the weakrefs backreferences array is used
or freed, the code checks whether the array has already been freed
and if so skips. Since the array already being freed is a bad bug,
lets instead assert that this never happens, based on the
assumptions that (a) such premature freeing bugs are likely ironed
out by now, (b) if they aren't then we want to know about them and
fix them rather than silently skip.
p4raw-id: //depot/perl@34210
|
|
|
|
|
|
|
|
|
|
|
| |
A weakref to a HV would leak, because the xhv_backreferences
array is created with a refcount of 2 (to avoid premature freeing
during global destruction), but the RC was only decremented once
when the parent HV was freed.
Also, when thread cloned, the new array was being created with a
RC of 1, rather than 2, which coincidentally worked due to the
first bug.
p4raw-id: //depot/perl@34209
|
|
|
|
|
|
| |
34138, spotted by Jerry D. Hedden. I assume that he's compiling with
options that enable trace flow analysis from the C compiler.
p4raw-id: //depot/perl@34144
|
|
|
|
|
|
| |
SV's buffer should be full-on panics, as bogus values passed in can
cause later heap corruption, which is a bad thing (TM).
p4raw-id: //depot/perl@34138
|
|
|
|
|
| |
buffer of the SV.
p4raw-id: //depot/perl@34136
|
|
|
|
|
| |
formed with a trailing '\0'. And do assume that bytes_to_utf8() does.
p4raw-id: //depot/perl@34128
|
|
|
|
|
| |
Message-ID: <20080628160017.GA81579@osiris.mauzo.dyndns.org>
p4raw-id: //depot/perl@34092
|
|
|
|
|
|
|
| |
(the ones that change #34077 missed). It also degrades some print
warnings - ie variable names no longer displayed.
p4raw-link: @34077 on //depot/perl: 8b0dea507b8f946d8546917b8fda74bfbf233ac0
p4raw-id: //depot/perl@34084
|
|
|
|
|
|
| |
Ops that can return undef even for defined args, could mistakenly
warn that the arg was undefined.
p4raw-id: //depot/perl@34077
|
|
|
|
|
| |
of SVs allocated at runtime
p4raw-id: //depot/perl@33854
|
|
|
|
|
| |
Message-ID: <20080505161856.pgz4pjga1w44ksk4@horde.wizbit.be>
p4raw-id: //depot/perl@33815
|
|
|
| |
p4raw-id: //depot/perl@33807
|
|
|
|
|
|
|
| |
fread() on VMS, and have been for some time. Except that ain't gonna
work with PerlIO::Scalar's in-memory files. Old bug exposed by new
test in #33769.
p4raw-id: //depot/perl@33788
|
|
|
| |
p4raw-id: //depot/perl@33669
|
|
|
|
|
|
| |
From: "Vincent Pit" <perl@profvince.com>
Message-ID: <34395.147.210.17.175.1207039697.squirrel@147.210.17.175>
p4raw-id: //depot/perl@33668
|