| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This is in preparation for the current wrapee becoming deprecated
|
| |
|
|
|
| |
This fairly short paradigm is repeated in several places; a later commit
will improve it.
|
| |
|
|
|
| |
Otherwise when compiling XS code, there is a declaration for a function
which is never used, which can cause some compilers to issue a warning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check for the nul char in pathnames and string arguments to
syscalls, return undef and set errno to ENOENT.
Added to the io warnings category syscalls.
Strings with embedded \0 chars were prev. ignored in the syscall but
kept in perl. The hidden payloads in these invalid string args may cause
unnoticed security problems, as they are hard to detect, ignored by
the syscalls but kept around in perl PVs.
Allow an ending \0 though, as several modules add a \0 to
such strings without adjusting the length.
This is based on a change originally by Reini Urban, but pretty much
all of the code has been replaced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The value of pos() is stored as a byte offset. If it is stored on a
tied variable or a reference (or glob), then the stringification could
change, resulting in pos() now pointing to a different character off-
set or pointing to the middle of a character:
$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, a; print pos $x'
2
$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, "\x{1000}"; print pos $x'
Malformed UTF-8 character (unexpected end of string) in match position at -e line 1.
0
So pos() should be stored as a character offset.
The regular expression engine expects byte offsets always, so allow it
to store bytes when possible (a pure non-magical string) but use char-
acters otherwise.
This does result in more complexity than I should like, but the alter-
native (always storing a character offset) would slow down regular
expressions, which is a big no-no.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for #119161.
On 64-bit platforms, I32 is too small to hold offsets into a stack
that can grow larger than I32_MAX. What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices, corrupting memory, and causing crashes.
With this commit, ()=1..1000000000000 stops crashing immediately.
Instead, it gobbles up all your memory first, and then, if your com-
puter still survives, crashes. The second crash happesn bcause of
a similar bug with the argument stack, which the next commit will
take care of.
|
| |
|
|
|
|
| |
This commit adds #if's to cause locale handling code to compile on
platforms that don't have full-featured locale handling. The commits
mentioned in the ticket did not adequately cover these situations.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c82ecf346.
It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread. So when you free the cop, how do you know where to do
SvREFCNT_dec?
In reverting c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves having to allocate a separate string buffer for every cop
(control op; every statement has one).
Under non-threaded builds, every cop has a pointer to the GV for that
source file, namely *{"_<filename"}.
Under threaded builds, the name of the GV used to be stored instead.
Now we store an offset into the per-interpreter PL_filegvpad, which
points to the GV.
This makes no significant speed difference, but it reduces mem-
ory usage.
|
| |
|
|
|
|
|
|
|
| |
This changes the previously unused _invlist_dump() function to be called
from sv_dump() to dump inversion list scalars. The format for regular
SVt_PVs doesn't give human-friendly output for these.
Since these lists are currently not visible outside the Perl core, the
format is documented only in comments in the function itself.
|
| |
|
|
| |
This code that appears twice is nearly duplicate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a closure closes over a variable, it references the variable
itself, as opposed to taking a snapshot of its value.
This was broken by the constant optimisation added for
constant.pm’s sake:
{
my $x;
sub () { $x }; # takes a snapshot of the current value of $x
}
constant.pm no longer uses that mechanism, except on older perls, so
we can remove this hack, causing code like this this to start work-
ing again:
BEGIN{
my $x = 5;
*foo = sub(){$x};
$x = 6
}
print foo; # now prints 6, not 5
|
| |
|
|
|
|
|
|
|
|
|
| |
These are inlined the same way as 1..5. We have two ops:
rv2av
|
`-- const
The const op returns an AV, which is stored in the op tree, and then
rv2av flattens it.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac.
Which reverted parts of f019c49e380f764c1ead36fe3602184804292711, but that
reversion may no longer be necessary.
See [perl #116989]
|
| |
|
|
|
|
|
|
|
| |
This, similar to sv_pos_u2b_flags, is a more friendly variant of
sv_pos_u2b that works with 2GB strings and actually returns a
value instead of modifying a passed-in value in place through
a pointer.
The next commit will use this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second try. 5969c5766a5d3 had a bug in it under non-
MAD builds.
If I have a sub I can use its name as a bareword as long as I suffix
it with =>, even if the => is on the next line:
$ ./perl -Ilib -e 'sub tim; warn tim' -e '=>'
tim at -e line 1.
If I want to use a built-in keyword’s name as a bareword, I can put =>
after it:
$ ./perl -Ilib -e 'warn time =>'
time at -e line 1.
But if I combine the two (keyword + newline), it does not work:
$ ./perl -Ilib -e 'warn time' -e ' =>'
1373611283 at -e line 1.
unless I override the keyword:
$ ./perl -Ilib -Msubs=time -e 'warn time' -e ' =>'
time at -e line 1.
=> after a bareword is checked for in two places in toke.c. The first
comes before a comment saying ‘NO SKIPSPACE BEFORE HERE!’; it only
skips spaces and finds a => on the same line. The second comes later;
it skips vertical space and comments, too.
But the second check is in a code path that is not reached by keywords
that are not overridden (as is the ‘NO SKIPSPACE’ comment).
This commit adds an extra check for built-in keywords after we have
determined that the keyword is not overridden. In that case, there is
no reason we cannot use skipspace, as we no longer have to worry about
what PL_oldbufptr etc. point to.
This commit leaves __DATA__ and __END__ alone, since they
are special, problematic and controversial. (See, e.g.,
<https://rt.perl.org/rt3/Ticket/Display.html?id=78348#txn-1234355>.)
Allowing whitespace to be scanned across line boundaries without
increasing the line number (something this commit has to do to make
this work) can cause the way PL_linestr is handled to change.
PL_linestr usually holds just the current line when reading from a
handle. Now it can hold the current line plus the next line or seve-
ral lines, depending on how much whitespace is to be found there.
When '\n' or '#' was encountered, the lexer would modify the buffer in
place and add a null, setting PL_bufend to point to that null. That
would make it look as though the end of the line had been reached, and
avoided having to scan to find the end of a comment.
In string eval and quote-like operators, the end of the comment does
have to be scanned for. We can’t just fake EOL and read the next
line of input.
Under MAD builds, the end of the comment was being scanned for any-
way, even when reading from a handle. So everything worked under MAD,
which was what I tested 5969c5766a5d3 under.
This commit changes the '\n' and '#' handling to match the MAD code
(scan for the end of the comment instead of faking a buffer trunca-
tion), which 5969c5766a5d3 failed to do.
|
| |
|
|
|
|
|
| |
The number of elements in an inversion list is a simple calculation
based on SvCUR(). Prior to this patch there was a field that contained
that number directly, and the two values diverged, causing a bug. A
single value can't get out-of-sync with itself.
|
| |
|
|
|
|
|
| |
The function invlist_set_len() has to be called after the offset header
field in an inversion list has been set. To make sure that future
maintainers don't forget to do this, add the parameter for the 'offset'
to its call, so it can't be called without having this value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0b58015e05b2ab93b080b7c49a70bf82435363c0, which
reverted 875c4e2c5193b5245da578b222e9c93aad31d93b, thus reinstating the
latter commit. It turns out that the error being chased down was not
due to this commit.
Its original message was (slightly revised for clarity):
These have always been slightly misnamed, but a recent commit made them
more so. The old name contained "zero", but now there is a new element
which always has zero. The renamed element indicates whether the
inversion list is offset, that is if the beginning is the zero element,
or if the beginning is the next element beyond the zero element.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c7995b20ccfbb4248b23aeae9fd1eab838852fcc, which
reverted 4b98096221966ea01c046f4f61b2dc4f60b534b9, thus reinstating
the latter commit. It turns out that the error being chased down was
not due to this commit.
Its original message was:
This removes a field that is set in the inversion list data structure
and examined just once. And that sole examiner is the function that
calls the function that does the set. In other words X calls Y passing
it data D. Y puts D into a structure. Upon return from Y, X looks for
D in the structure. No one else looks at D. X might just as well have
looked at D directly, without involving Y, and without the structure
needing a space for D.
|
| |
|
|
|
|
|
|
|
| |
When elements of @_ refer to nonexistent hash or array elements, then
the magic scalar in $_[0] delegates all set/get actions to the element
in represents, vivifying it if needed.
tie/tied/untie, however, were not delegating to the element, but were
tying the the magical ‘deferred element’ scalar itself.
|
| |
|
|
|
|
|
|
|
| |
When elements of @_ refer to nonexistent hash or array elements, then
the magic scalar in $_[0] delegates all set/get actions to the element
in represents, vivifying it if needed.
pos($_[0]), however, was not delegating the value to the element, but
storing it on the magical ‘deferred element’ scalar.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assigning a vstring to a tied variable would result in a plain string
in $_[1] in STORE.
Assigning a vstring to a magic deferred element would result in a
plain string in the aggregate’s actual element.
When magic is invoked, the magic flags are temporarily turned off on
the sv so that recursive calls to magic don’t happen. This makes it
easier to implement functions like Perl_magic_set to read the value of
the sv without triggering get-magic.
Since vstrings are only considered vstrings when they are SvRMAGICAL,
this meant that set-magic would turn vstrings temporarily into plain
strings. Subsequent copying (e.g., in STORE) would then fail to copy
the vstring magic.
This commit changes mg_set to leave the rmagical flag on, since it
does not affect the functionaiity of set-magic.
|
| |
|
|
|
|
| |
This reverts commit 5969c5766a5d3f6b42a5140548d7c3d6812fec8b.
It appears to be failing with non-mad builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If I have a sub I can use its name as a bareword as long as I suffix
it with =>, even if the => is on the next line:
$ ./perl -Ilib -e 'sub tim; warn tim' -e '=>'
tim at -e line 1.
If I want to use a built-in keyword’s name as a bareword, I can put =>
after it:
$ ./perl -Ilib -e 'warn time =>'
time at -e line 1.
But if I combine the two (keyword + newline), it does not work:
$ ./perl -Ilib -e 'warn time' -e ' =>'
1373611283 at -e line 1.
unless I override the keyword:
$ ./perl -Ilib -Msubs=time -e 'warn time' -e ' =>'
time at -e line 1.
=> after a bareword is checked for in two places in toke.c. The first
comes before a comment saying ‘NO SKIPSPACE BEFORE HERE!’; it only
skips spaces and finds a => on the same line. The second comes later;
it skips vertical space and comments, too.
But the second check is in a code path that is not reached by keywords
that are not overridden (as is the ‘NO SKIPSPACE’ comment).
This commit adds an extra check for built-in keywords after we have
determined that the keyword is not overridden. In that case, there is
no reason we cannot use skipspace, as we no longer have to worry about
what PL_oldbufptr etc. point to.
This commit leaves __DATA__ and __END__ alone, since they
are special, problematic and controversial. (See, e.g.,
<https://rt.perl.org/rt3/Ticket/Display.html?id=78348#txn-1234355>.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was buggy code to see if the start-up locale is UTF-8. This
commit extracts it into a separate function.
The bugs involved looking at the name of the locale to see if that
implies a UTF-8 name. Prior to this commit, it looked at the
beginning of the locale name, whereas in reality, it is at the end, as
in "fr_FR.UTF8".
Also, it didn't look for the documented Windows name for UTF-8 locales
on those platforms.
The function is expanded to have an input category to find the utf8ness
of. Thus it now works on any non-LC_ALL category, not just LC_CTYPE.
It is possible for categories to be in different locales, so that
LC_CTYPE is in a UTF-8 locale, and LC_NUMERIC isn't. For the purposes
of PERL_UNICODE, the most applicable category is LC_CTYPE, so that is
the one used in its currently only call.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code to do warnings on invalid prototypes was a chunk
of 70 or so lines inside the core lexer. It also had the
side effect of removing spaces from the prototype as part
of its check for warnings.
This validation code is now just a validation, printing
out warnings if and only if warnings are enabled,
and leaving the source SV untouched.
|
| |
|
|
|
|
|
| |
This reverts commit 4b98096221966ea01c046f4f61b2dc4f60b534b9.
This continues the backing out of this topic branch. A bisect shows
that the first commit exhibiting an error is the first one in the
branch.
|
| |
|
|
|
|
|
| |
This reverts commit 875c4e2c5193b5245da578b222e9c93aad31d93b.
This continues the backing out of this topic branch. A bisect shows
that the first commit exhibiting an error is the first one in the
branch.
|
| |
|
|
|
|
|
|
| |
These have always been slightly misnamed, but a recent commit made them
more so. The old name contained "zero", but now there is a new element
which always has zero. This element indicates whether the inversion
list is offset, that is if the beginning is the zero element, or if the
beginning is the next element beyond the zero element.
|
| |
|
|
|
|
|
|
|
|
| |
This removes a field that is set in the inversion list data structure
and examined just once. And that sole examiner is the function that
calls the function that does the set. In other words X calls Y passing
it data D. Y puts D into a structure. Upon return from Y, X looks for
D in the structure. No one else looks at D. X might just as well have
looked at D directly, without involving Y, and without the structure
needing a space for D.
|
| |
|
|
|
| |
Every single caller passes gv_ename(namegv), so make it accept a GV
instead and have *it* call gv_ename(namegv).
|
| |
|
|
| |
"aaabc" should match /a+?(*THEN)bc/ with "abc".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Over the years, every caller which used this hack had it progressively
turned off. Prior to this commit, only one call remained, which
ostensibly handled this case:
format 'STDOUT = ...
However, turns out that even there it was superflous, since a scan_word
a dozen lines before will've already turned all ticks into double
colons.
|
| |
|
|
|
|
|
|
|
|
| |
A micro-optimization inspired by bulk88's perl #115112.
The original proposal suggested applying a two changes that removed the
duplicate calls, and then explicitly inlined path_is_absolute().
This version removes the duplicate calls, renames the function to better
match it's purpose and asks the compiler to inline it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(note that this is a change both to the perl API and the regex engine
plugin API).
Currently, Perl_re_intuit_start() is passed an SV, plus pointers to:
where in the string to start matching (strpos); and to the end of the
string (strend).
Unlike Perl_regexec_flags(), it doesn't also have a strbeg arg.
Because of this this, it guesses strbeg: based on the passed SV (if its
svPOK()); or just set to strpos otherwise. This latter can happen if for
example the SV is overloaded. Note also that this latter guess is wrong,
and could in theory make /\b.../ fail.
But just to confuse matters, although Perl_re_intuit_start() itself uses
its guesstimate strbeg var, some of the functions it calls use the global
value of PL_bostr instead. To make this work, the *callers* of
Perl_re_intuit_start() currently set PL_bostr first. This is why \b
doesn't actually break.
The fix to this unholy mess is to simply add a strbeg arg to
Perl_re_intuit_start(). It's also the first step to eliminating PL_bostr
altogether.
|
| |
|
|
|
|
| |
Remove the is_utf8_pat arg from these two static functions in regexec.c.
Since both these functions are now passed a valid reginfo pointer, this
info is already available as one of the fields in that struct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regmatch_info is a small struct that is currently directly allocated as a
local var in Perl_regexec_flags(), and has a few fields that maintain part
of the state of the current pattern match. It is passed as an arg to
various functions that regexec_flags() calls, such as regtry().
In some ways its a rival to PL_reg_state, which also maintains state for
the current match, but which is a global variable (whose state needs
saving and restoring whenever the regex engine goes reentrant). It makes
more sense to store state in the regmatch_info struct, and as a first step
in moving more state to there, this commit makes more use of
regmatch_info.
In particular, it makes Perl_re_intuit_start() also allocate such a
struct, so that now *both* the main execution entry points to the regex
engine make use of it. It's also now passed as an arg to more of the static
functions that these two op-level ones call.
Two changes of special note. First, whether S_find_byclass() got called
with a null reginfo pointer of not indicated whether it had been called
from Perl_regexec_flags() (with a valid reginfo pointer), or from
Perl_re_intuit_start() (null pointer). Since they both pass non-null
reginfo pointers now, instead we add an extra field, reginfo->intuit that
indicates who's the top-level caller.
Secondly, to allow in future for various macros to uniformly refer to
values like reginfo->foo, where the structure is actually allocated as a
local var in Perl_regexec_flags(), we change the reginfo from being the
struct itself to being a pointer to the struct, (so Perl_regexec_flags
itself now uses reginfo->foo too rather than reginfo.foo).
In summary, all the above is essentially window dressing that makes no
functional changes to the code, but will facilitate future changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Peter Martini noted in ticket #116735, lexical subs produce dif-
ferent op trees for ‘foo 1’ and ‘foo(1)’. foo(1) produces an rv2cv
op with a padcv kid. The unparenthetical version produces just
a padcv op.
And the difference in op trees caused lexical sub calls to honour
prototypes only in the presence of parentheses, because rv2cv_op_cv
(which searches for the cv in order to check its prototype) was
expecting rv2cv+padcv.
Not realising there was a discrepancy between the two forms, and
noticing that foo() produces *two* newCVREF ops, in commit 279d09bf893
I made newCVREF return just a padcv op for lexical subs. At the time
I couldn’t figure out why there were two rv2cv ops, and punted on
researching it.
This is how it works for package subs:
When a sub call is compiled, if there are parentheses, an implicit '&'
is fed to the parser. The token that follows is a WORD token with a
constant op attached to it, containing the name of the subroutine.
When the parser sees '&', it calls newCVREF on the const op to create
an rv2cv op.
For sub calls without parentheses, the token passed to the parser is
already an rv2cv op.
The resulting op tree is the same either way.
For lexical subs, I had the lexer emitting an rv2cv op in both paths,
which was why we got the double rv2cv when newCVREF was returning an
rv2cv for lexical subs.
The real solution is to call newCVREF in the lexer only when there
are no parentheses, since in that case the lexer is not going to call
newCVREF itself. That avoids a redundant newCVREF call. Hence, we
can have newCVREF always return an rv2cv op.
The result is that ‘foo(1)’ and ‘foo 1’ produce identical op trees for
a lexical sub.
One more thing needed to change: The lexer was not looking at the
lexical prototype CV but simply the stub to be autovivified, so it
couldn’t see the parameter prototype attached to the CV (the stub
doesn’t have one).
The lexer needs to see the parameter prototype too, in order to deter-
mine precedence.
The logic for digging through pads to find the CV has been extracted
out of rv2cv_op_cv into a separate (non-API!) routine.
|
| |
|
|
| |
It is not marked as part of the API, and no code on CPAN is using it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
These are now only being used for mixed-endian platforms which do not
provide their own htnol (etc) functions. Given that the fallbacks have been
buggy since they were added in Perl 3.0, it's safe to conclude that no
mixed-endian platforms were ever using these functions.
It's also unclear why these functions were ever marked as 'A', part of the
API. XS code can't call them directly, as it can't rely on them being
compiled. Unsurprisingly, no code on CPAN references them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds support for PERL_PERTURB_KEYS environment variable, which in turn allows one to control
the level of randomization applied to keys() and friends.
When PERL_PERTURB_KEYS is 0 we will not randomize key order at all. The
chance that keys() changes due to an insert will be the same as in
previous perls, basically only when the bucket size is changed.
When PERL_PERTURB_KEYS is 1 we will randomize keys in a non repeatedable
way. The chance that keys() changes due to an insert will be very high.
This is the most secure and default mode.
When PERL_PERTURB_KEYS is 2 we will randomize keys in a repeatedable way.
Repititive runs of the same program should produce the same output every
time. The chance that keys changes due to an insert will be very high.
This patch also makes PERL_HASH_SEED imply a non-default
PERL_PERTURB_KEYS setting. Setting PERL_HASH_SEED=0 (exactly one 0) implies
PERL_PERTURB_KEYS=0 (hash key randomization disabled), settng PERL_HASH_SEED
to any other value, implies PERL_PERTURB_KEYS=2 (deterministic/repeatable
hash key randomization). Specifying PERL_PERTURB_KEYS explicitly to a
different level overrides this behavior.
Includes changes to allow one to compile out various aspects of the
patch. One can compile such that PERL_PERTURB_KEYS is not respected, or
can compile without hash key traversal randomization at all. Note that
support for these modes is incomplete, and currently a few tests will
fail.
Also includes a new subroutine in Hash::Util::hash_traversal_mask()
which can be used to ensure a given hash produces a predictable key
order (assuming the same hash seed is in effect). This sub acts as a
getter and a setter.
NOTE - this patch lacks tests, but I lack tuits to get them done quickly,
so I am pushing this with the hope that others can add them afterwards.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to resolve these three related tickets:
[perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
[perl #117319] Can't include perl.h without linking to libperl
[perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)
This patch changes S_croak_memory_wrap from a static (but not inline)
function into an ordinary exported function Perl_croak_memory_wrap.
This has the advantage of allowing programs (particuarly probes, such
as in cflags.SH and Time::HiRes) to include perl.h without linking
against libperl. Since it is not a static function defined within each
compilation unit, the optimizer can no longer remove it when it's not
needed or inline it as needed. This likely negates some of the savings
that motivated the original commit 380f764c1ead36fe3602184804292711.
However, calling the simpler function Perl_croak_memory_wrap() still
does take less set-up than the previous version, so it may still be a
slight win. Specific cross-platform measurements are welcome.
|
| |
|
|
|
|
|
|
|
|
|
| |
The SV listsv is sometimes stored in an array generated near the end of
S_regclass(). In other cases it is not used, and it needs to be freed if
any of the warnings that S_regclass() can trigger turn out to be fatal.
The simplest solution to this problem is to declare it from the start as a
mortal, and claim a (new) reference to it if it is *not* to be freed. This
permits the removal of all other code related to ensuring that it is freed
at the right time, but not freed prematurely if a call to a warning returns.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds:
S_ptr_hash() - A new static function in hv.c which can be used to
hash a pointer or integer.
PL_hash_rand_bits - A new interpreter variable used as a cheap
provider of "semi-random" state for use by the hash infrastructure.
xpvhv_aux.xhv_rand - Used as a mask which is xored against the
xpvhv_aux.riter during iteration to randomize the order the actual
buckets are visited.
PL_hash_rand_bits is initialized as interpreter start from the random
hash seed, and then modified by "mixing in" the result of ptr_hash()
on the bucket array pointer in the hv (HvARRAY(hv)) every time
hv_auxinit() allocates a new iterator structure.
The net result is that every hash has its own iteration order, which
should make it much more difficult to determine what the current hash
seed is.
This required some test to be restructured, as they tested for something
that was not necessarily true, we never guaranteed that two hashes with
the same keys would produce the same key order, we merely promised that
using keys(), values(), or each() on the same hash, without any
insertions in between, would produce the same order of visiting the
key/values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Namely:
* The first character in ${...} used to have no restrictions
* ${foo:bar} used to be legal
* ${foo::bar} worked, but ${foo'bar} didn't
And possibly other subtle, so far undiscovered bugs. This was
resolved by simply using the same code for both things.
Note that this commit is not entirely useful on its own; While
tests pass, it requires changes from the following commit to work
entirely.
|
