| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Indent code that now has a newly formed block around it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Input constructs that expand to more than one character are handled very
very specially when they occur within a bracketed character class. What
happens effectively is that they are removed from the class and parsed
separately, using the regular code in regcomp.c to generate something
like a trie for them. The other characters within the class are handled
normally.
The specially handled stuff is parsed from a separate string. In the
case where that stuff is of the form \N{U+...}, I neglected to
adequately consider that the syntax could trigger an error. When such
an error is raised, it can violate our assumptions about the state of
things, and lead to a panic.
THe code actually parses the construct twice. The first time while
deciding if this expands to multiple characters (so that it can be
separated out), and the second time to actually figure out and return
the expansion. This commit fixes the bug by adding error checking
during the first pass. Previously, the minimal amount of work was done
to be able to find the count of characters in the expansion. Now, more
work is done to do the checking, as we go along with the counting. This
actually results in less special case code needing to be executed, so
there is a net code removal from this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On debugging builds, the code in the ticket instead fails an assert. I
thought I had previous failures figured out, but it turns out I was
wrong. To prevent potential security failures by going ahead and
printing memory known to be outside what we are expecting on
non-debugging builds, instead panic.
This doesn't fix the underlying problem of how we came to be trying to
output bad stuff, but it keeps all such cases from being security
bugs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This loop was inadvertently introduced as part of patches to fix
(perl #132227 CVE-2018-6797] heap-buffer-overflow". The commit in 5.27
responsible was f8fb8615ddc5a80e3bbd4386a8914497f921b62d.
To be vulnerable, the pattern must start out as /d (hence no use 5.012
or higher), and then there must be something that implicitly forces /u
(which the \pp does in the test case added by this patch), and then
(?aa), and then the code point \xDF. (German Sharp S). The /i must be
in effect by the time the DF is encountered, but it needn't come in the
(?aa) which the test does.
The problem is that the conditional that is testing that we switched
away from /d rules is assuming that this happened during the
construction of the current EXACTFish node. The comments I wrote
indicate this assumption. But this example shows that the switch can
come before this node started getting constructed, and so it loops.
The patch explicitly saves the state at the beginning of this node's
construction, and only retries if it changed during that construction.
Therefore the next time through, it will see that it hasn't changed
since the previous time, and won't loop.
|
| |
|
|
|
| |
The code did not consider the case of a trailing slash with no
denominator following it. Simply add a check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a blatant kludge to work around a failing test in
Lexical::SealRequireHints. The test is wrong, checking for an internal
detail that has changed.
This commit adds a conditional for the exact input that's failing, and
if found, uses the old method, so the test passes.
The failing input is the regex pattern
foo\p{Alnum}
'foo' is unlikely to be found in practice outside of .t files, and
this particular pattern rarely even in those. So this should not slow
down real production code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8e920bd341e241f50a74dbf8aa343319f204e200.
Also skip the tests in t/op/blocks.t
RT #132863
8e920bd341 sets the PERL_EXIT_DESTRUCT_END flag on non-UNIXy platforms,
like is already done on UNIXy platforms. This makes things like
BEGIN { exit(1) } call END blocks on those platforms (like they already
do on UNIX).
But it caused problems with win32 pseudo-forks, so revert for 5.28
and re-address the issues sometime later.
|
| |
|
|
|
| |
Apart from the whitespace change, this just wraps 6 tests in
a SKIP: { ... } block which isn't (yet) used.
|
| |
|
|
|
|
|
|
| |
Put the three tests skipped under VMS together into a single SKIP
block rather than 3 separate skips.
As well as being tidier, as a side effect, it makes 6 tests contiguous
that are shortly to be skipped under win32,
|
| |
|
|
| |
Makes the tests a bit easier to read.
|
| |
|
|
| |
RT #133172
|
| |
|
|
|
|
|
|
|
|
|
| |
RT #133184
pp_crypt() directly manipulates a field inside 'struct crypt_data' to work
around a bug in an ancient glibc version from circa 2002. New glibc
releases don't have this field so perl fails to compile. Make the hack
conditional on glibc version.
Stolen from a patch to the Fedora 28 distribution.
|
| |
|
|
|
|
|
|
|
|
| |
Setting the pointer to NULL after freeing signals the code in later
interations that it has been freed already
No test is added because it could become outdated (not testing what it
was designed to test) with a new Unicode version changing the underlying
data. This bug was discovered by testing on Unicode 7.0, and the data
changed so that there was not a problem by Unicode 10.0.
|
| |
|
|
|
|
|
|
| |
RT #133120
Spotted by Alexandr Savca
Change approved by Makoto Nozaki of TPF
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some t/op/sprintf2.t tests were failing under g++. This is due the perl
toker interpreting very small literal hex floating pointers as 0 rather
than as a subnormal value.
For example:
perl -le'print "bad" if 0x1.fffffffffffffp-1022 == 0.0'
This breaks some of the sprintf2.t tests, so mark them TODO them if the
literal value evaluates to zero.
Note that this is a bug in the toker/g++/glibc rather than sprintf.
The issue is due to the use of pow() in scan_num():
under gcc and plain g++, pow(2.0, -1074) returns the smallest denorm
number; however, under 'g++ -ansi', it returns 0.0.
|
| |
|
|
|
|
|
|
|
| |
Tux reported that on certain platforms File::Temp::tempdir(CLEANUP => 1) was
not cleaning up after itself properly. Guarantee that this cleanup takes
place in and END block.
Thread:
https://www.nntp.perl.org/group/perl.perl5.porters/2018/04/msg250757.html
|
| |
|
|
|
|
| |
There is a bug in Solaris with locales which have a multi-byte decimal
radix character. Make these TODO, like we do cygwin, which has had a
similar problem.
|
| |
|
|
|
|
|
| |
We now have found a system that fails this test. Tests that are listed
as problematic automatically get marked as TODO when they fail with
specified platforms. The next commit will specify the platform that
this is fails on.
|
| |
|
|
|
|
| |
Solaris is buggy in dealing with locales that have a multi-byte UTF-8
decimal radix character. Skip using these, like we do on cygwin, which
has a similar problem.
|
| |
|
|
|
|
|
| |
Until it's fixed upstream, we should skip tests that don't expect
this behaviour.
[RT #133141]
|
| |
|
|
|
|
|
|
|
|
| |
bisect runner is supposed to keep going if the particular revision being
tested fails to compile. But it wasn't.
Nicholas graciously diagnosed the problem. When the enhancement for
testing when a module got broken, the code to do so was placed before
the check to see if the build for this revision crashed. It's simply a
matter of moving that module code to after that check.
|
| |
|
|
|
|
|
|
| |
"true" token was added in commit 394d2d3f37 but "true" is C++ and C99,
"TRUE" is portable perl API
Win32 VC 2003 C mode (C89) build faiure
..\utf8.c(6177) : error C2065: 'true' : undeclared identifier
|
| |
|
|
|
|
| |
Dodge the "offsetof has a builtin meaning; use /Zc:offsetof- to revert to
old, non-conforming definition" error when compiling Socket.xs by reverting
to an old definition of STRUCT_OFFSET for that compiler.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f6107ca24b4cf22dcf7fd69d65612ad718c48fca.
See RT #132142.
For now, re-introduce the bug that fails to convert weak refs to strong
refs when sorting in place.
This is commit 2 of 2.
|
| |/
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5bad3c4f3a4515aaa622eecdf6f5a84fcaff7ed9.
See RT #132142.
For now, re-introduce the bug that fails to convert weak refs to strong
refs when sorting in place.
This is commit 1 of 2.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
RT #132955
Commit 0879cd66ef3f00 fixed perl to still build under C++ after changes
to PL_inf and PL_nan. Unfortunately this seems to have broken C++ builds
under Windows.
Handle the extern 'C' stuff in a different way - as suggested by Leon T -
that hopefully satisfies all platforms.
|
| | |
|
| |
|
|
|
|
| |
This, together with the previous commit, fixes the C++-mode build on
Windows using VS2017 except for the remaining problem with PL_nan when
linking POSIX - see RT#132955.
|
| | |
|
| |
|
|
|
|
| |
It was mistakenly picked up starting in 5.27.6 due to ad2ec6b54c and we
didn't notice: it should have never been added. Remove historical entries
and blacklist it so it doesn't come back.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revision of patch in #133098.
There is a problem described in #133125 with XS-APITest using with "Perl_"
mathomed C symbols instead of the Perl_-less ones which would get
preprocessor redirected to newer C funcs, then link failure of XS-APITest
on Win32 because missing symbols. These symbols were missing because they
were marked "m" and I thought in commit 1545ba5b04 "m" means no C symbol,
ever, but that isn't true. It seems that "b" means must export on a
with-mathoms default perl. So put back part of the original code before
commit 1545ba5b04 from commit 3f1866a8f6, so that on with mathoms builds
all "b"s are exported, but on no mathom builds, all "b"s are removed/not
exported.
There are some logic holes here for strange or impossible combinations
of flags, like flags "Abi" or just "b" without "A", that I wont address
here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7c114860c0fa8ade5e00a4b609d2fbd11d5a494c introduced an optimisation
in pp_iter(). Before the optimisation, pp_iter() pushed either &PL_SV_yes or
&PL_sv_no to the stack, and returned the op_next in the obvious way.
The optimisation takes advantage of the fact that the op_next of an OP_ITER
always points to an OP_AND node, so pp_iter() now directly jumps to either
the op_next or the op_other of the OP_AND as appropriate.
The commit message for the optimisation also says this:
It's possible that some weird optree-munging XS module may break this
assumption. For now I've just added asserts that the next op is OP_AND
with an op_ppaddr of Perl_pp_and; if that assertion fails, it may be
necessary to convert pp_iter()s' asserts into conditional statements.
However, Devel::Cover does change the op_ppaddr of the ops it can see, so
the assertions on op_ppaddr were being tripped when Devel::Cover was run
under a -DDEBUGGING Perl. But even if the asserts didn't trip, skipping the
OP_AND nodes would prevent Devel::Cover from determining branch coverage in
the way that it wants.
This commit converts the asserts into conditional statements, as outlined in
the commit message above, and undoes the optimisation when the op_ppaddr
doesn't match.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
