| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Unwind the innermost loop, used only for reporting, and remove the array @s,
only used to accumulate results for that loop. Fewer lines, less complexity,
better diagnostics, and with the same failure cases on 3e6bd4bfcd175c61^.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 56ca34cada940c7f6aae9a59da266e541530041e had the side effect of
causing regular expressions with things like [a-z], or even just [k] to
go out to disk to read tables to create swashes because it knew that
some of those characters matched outside the bitmap (and due to
l1_char_class_tab.h it knew which ones had those matches), but it didn't
know what the characters were that participated in those folds.
This patch hard-codes the Unicode 6.0 rules into regcomp.c for the
code points 0-255, so that the very slow utf8_heavy is not invoked on
them. (Code points above 255 will continue to invoke it.) It would,
of course, be better if these rules could be regen'd into regcomp.c, as
there is a risk that the standard will change, and the code will not.
But I don't think that has ever happened; in other words, I think that
the rules haven't changed so far since Day 1 of Unicode. (That would
not be the case if we were doing simple case folding, as the capital
sharp ss which folds to U+00DF was added later.) And the Standard is
getting more stable in this area. I believe one of their stability
policies now forbid them from adding something that simply folds to
one of the characters that already has a fold, such as M and m.
Ligatures are frowned on, and I doubt that new ones would be encoded,
so that leaves a new Unicode character that folds to a Latin-1 plus some
sort of mark. For those, this code is a no-op, so those aren't a
problem either.
|
| | |
|
| |
|
|
|
| |
This sets things up in preparation for a future commit that will
move calculating all folds involving characters in the bit map.
|
| |
|
|
|
| |
The set_regclass_bit functions will be adding to a new inversion list.
This declares that list and passes it to them.
|
| | |
|
| |
|
|
|
|
| |
A pointer to the list of multi-char folds in an ANYOF node is now passed
to the routines that set the bit map. This is in preparation for those
routines to add to the list
|
| |
|
|
|
| |
The code that handles a false range in a [character class] hadn't been
converted to use inversion lists
|
| |
|
|
|
| |
This is just an inline shorthand when a single code point is all that is
needed. A macro could have been used instead, but this just seemed nicer.
|
| |
|
|
|
|
| |
THis is part of the refactoring of the code that sets the alternate array
for multi-char folds. Changing the node type to ANYOFV can be done at
the last second, in pass 2, as it doesn't change any sizing, etc.
|
| |
|
|
| |
A future commit uses this same code, so put it into a common place.
|
| |
|
|
|
| |
These will be used in a future commit; the ordinals are different on
EBCDIC vs. ASCII
|
| |
|
|
|
| |
These were defined in a .c, but now there is need for them in another .c,
so move them to a header.
|
| |
|
|
|
| |
A previous commit changed add_range_to_invlist() to do the creation
that these lines did.
|
| |
|
|
|
|
|
| |
Change the function add_range_to_invlist() to accept NULL as the
inversion list, in which case it creates it. A common usage of this
function is to create the list if it doesn't exist before calling it, so
this just makes that code once.
|
| |
|
|
|
|
| |
Commit 72b166521443a1b8 changed perl to using File::Glob to implement the glob
builtin. Previously glob was implemented by spawning a csh, hence globbing was
not allowed on tainted values. The test for this was skipped, but never removed.
|
| |
|
|
|
|
| |
Without this, if $...::AUTOLOAD ever becomes tainted, it will never
subsequently become properly untainted. This fixes an omission in change
5d121f7f3e622b95.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #84982]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=84982 >
Remove _new() from XS code and use _new() in Math::BigInt::Calc
instead. The XS _new() doesn't handle integers that are too large to
be represented exactly as floating point numbers, but small enough
to be represented as 64 bit integers. E.g., even with 64 bit integer
support, applying _num() to 18446744073709551615 (= 2**64-1) gives
1.84467440737096e+19, not 18446744073709551615. The XS _new() also
returns nan, not inf, when it overflows. This closes RT #63335 and
RT #49569.
Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The || case in t/op/tie_fetch_count.t is not a bug, as there are two
separate operators operating on it in the test script. In
$dummy = $x || $y
The || does mg_get($x). If it’s true it returns it and the = does
mg_get($x). If $x is false, then $y is returned, so magic is called
once on each of $x and $y. Similarly, && will seemingly call
mg_get($x) twice if $x is false.
If you just write:
$x || $y
then magic is only called once on $x.
This patch corrects the test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two problems here.
String evals do not populate @{"_<..."} arrays the way parsed streams
do. The lines are all put into the array before the parse. Commit
e66cf94 added the code to copy (actually alias, but whatever) the
lines into the new array when a #line directive is encountered. Inte-
restingly, the following commit (8a5ee59) wrapped that code in an
#ifndef USE_ITHREADS block, because ‘[c]hange 25409 [e66cf94] wasn’t
necessary for threaded perls’. It seems it *was* necessary for
threaded perls after all, because the lines are simply not copied.
In non-threaded perls it wasn’t working properly either. The array
in the new glob was the same array as the old (aliased), so the line
numbers would be off if the #line directive contained a line number
that differed.
This commit does three things:
• It removes the #ifndef,
• It checks whether the line number has changed and aliases the indi-
vidual elements of the array.
• The breakpoints hash is not copied if the line number differs, as
setting a breakpoint on (eval 1):1 (warn 1) in
eval qq{warn 1;\n#line 1 "foo"\nwarn 2;}
should not also set a breakpoint on foo:1 (warn 2).
|
| |
|
|
|
| |
The bounds of this array were being exceeded causing smoke failures on
netbsd
|
| |
|
|
|
| |
Fixes Use of uninitialized value $ENV{"CYGWIN"} in concatenation (.) or string
at /usr/lib/perl5/5.13.10/i686-cygwin/Config_heavy.pl line 54
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported at nntp://nntp.perl.org/1298599236.4753.72.camel@p100 (and
respaced for readability):
#!perl5.12.0
$r=q/
print __FILE__;
local *dbline = $main::{"_<".__FILE__};
print $dbline[0]
/;
eval $r;'
__END__
(eval 1)
Bus error
This only seems to happen in non-threaded perls.
It can be reduced to this:
*d = *a; print $d[0];
The $d[0] is optimised into an aelemfast op (instead of the usual aelem
with an rv2av kid). pp_aelemfast is at fault, as evidenced by the fact
that this does not crash (the ${\...} prevents the optimisation):
*d = *a; print $d[${\0}];
pp_aelemfast uses GvAV instead of GvAVn. Usually $d[0] will autovivify
@d, but the glob assignment leaves $d[0] pointing to a glob (*d) with
no array. Then pp_alemfast passes a null pointer around.
|
| |
|
|
|
| |
We don't usually reference git commits anymore in perldelta, so let's stop
git-deltatool from generating entries like that.
|
| |
|
|
|
| |
My $EDITOR is 'emacsclient -t'. system('emacsclient -t', 'more', 'args') won't
do the right thing.
|
| |
|
|
| |
The pager code is mostly stolen from Prophet::CLI.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In perltie.pod the handle READLINE says
The method should return undef when there is no more data.
which made me think that's what it should always do, and didn't need to
pay attention to wantarray().
If I'm not mistaken in list context READLINE should return empty list
for no more data. It'd be good if the docs noted that, and perhaps
cross referenced to perlfunc for the gory details of what readline
should do.
Maybe something like the following, unless someone can think of a better
contrivance for the sample.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually, it doesn’t. The original test case was:
#!/usr/bin/perl
my $rx = qr'\$ (?| {(.+?)} | (.+?); | (.+?)(\s) )'x;
my $test = '/home/$USERNAME ';
die unless $test =~ $rx;
print "1: $1\n";
print "2: $2\n" if defined $2;
This crashes even if I put an ‘exit’ right after the pattern match.
What’s happening is that regcomp miscounts the number of capturing
parenthesis pairs (cf. [perl #59734]), so the execution of the regular
expression causes a buffer overflow which overwrites the op_sibling
field of the regcreset op, causing a crash when the op is freed. (The
exact failure may differ between builds, platforms, etc., of course.)
S_reg in regcomp.c keeps a count of the parenthesised groups in a
(?|...) construct, which it updates after each branch, if that branch
has more captures than any previous branch. But it was not updating
the count after the last branch.
So this bug would occur if the last branch had more capturing paren-
theses than any previous branch.
Commit ee91d26, which fixed bug #59734, only solved the problem when
there was just one branch (by updating the count before the loop that
deals with subsequent branches was entered).
This commit changes the code at the end of S_reg to take into account
that RExC_npar (the current paren count) might have been increased by
the last branch.
Since the loop to deal with subsequent branches resets the count
*before* each branch, the code that commit ee91d26 added is no longer
necessary, so this commit removes it.
|
| |
|
|
|
|
|
|
| |
This was from commit f424400810b6af341e96230836690da51c37b812
which came from needing a bit in an already-full flags field,
and my faulty analysis that two bits could be shared. I found another
mechanism to free up another bit, and now can separate these shared
bits again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the foundation for fixing the regression RT #82610. My analysis
was wrong that two bits could be shared, at least not without further
work. This changes to use a different mechanism to pass needed
information to regexec.c so that another bit can be freed up and, in a
later commit, the two bits can become unshared again.
The bit that is freed up is ANYOF_UTF8, which basically said there is
something that is matched outside the ANYOF bitmap, and requires the
target string to be in utf8. This changes things so the existence of
something besides the bitmap indicates this, and so no flag is needed.
The flag bit ANYOF_NONBITMAP_NON_UTF8 remains to indicate that there is
something that should be matched outside the bitmap even if the target
string isn't in utf8.
|
| | |
|
| |
|
|
| |
This just moves the code to later in the subroutine, in preparation for future commits
|
| |
|
|
|
|
| |
As the comment above the changed line says, \p doesn't have to match only
utf8, but it sets the flag that is two bits, meaning UTF8. Set just the
one flag.
|
| | |
|
| | |
|
| |
|
|
| |
We needed another upload to fix a PAUSE indexing problem.
|
| | |
|
| |
|
|
|
| |
From now on all changes will go through CPAN first and the Changes file is being
maintained there. No need to keep it around in the core.
|
| |
|
|
| |
make_ext.pl can generate it for us.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #84844]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=84844 >
Change default backend library from Math::BigInt::FastCalc to
Math::BigInt::Calc, which is included in the Math-BigInt distro.
This avoids recursive distribution dependency (RT #65976).
|
| |
|
|
|
|
| |
It was only being used in four places across two files, to add perforce
revision numbers to test descriptions. Replace this with the git commit hash
in the tests' descriptions.
|
| |
|
|
|
| |
This has been vestigial since 1c25d394345c1b97 converted it to using test.pl's
tempfile().
|
| |
|
|
|
|
|
| |
The addition of "OPTION random" to all fork.t's tests might be overkill, given
that run_multiple_progs() can specify "random" per test, but as the previous
code in fork.t always sorted before comparison, we are no *worse* off than we
were.
|
| |
|
|
|
| |
This will make it available to several tests in t/op, which currently duplicate
it.
|
