| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
These releases were made in 2018, not 2019.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
A change in 5.29.4 was misworded in its perldelta. Karl fixed the wording
in perl5294delta, and added the corrected text in this perldelta, under
the Core Enhancements section.
The Errata section is more appropriate.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This will also fix 128894 and 126144.
|
|
|
|
|
|
|
| |
In the (?[ ... ]) regex sets features, one can embed another compiled
regex set pattern. Such compiled patterns always have a flag of '^',
which we weren't looking for prior to this commit. That meant that
uncompiled patterns would be mistaken for compiled ones.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This was originally fixed in 5.29.4. The patch itself does have
an entry in the perldelta for 5.29.4, but it was, intentionally,
not made clear a security hole was fixed. This was delayed until
5.28.1 and 5.26.3 were released.
|
|
|
|
|
|
|
|
|
| |
The text of perl5294delta was wrong about a change. This commit changes
that text, and adds an entry to the latest perldelta with the
correction. A test has been added to verify the way things work.
The wrong language led to this blog post, and my comment in it:
https://www.effectiveperlprogramming.com/2018/12/perl-v5-30-lets-you-match-more-with-the-general-quantifier/
|
|
|
|
|
| |
This covers c6fe5b981b942ddabb23ed4b7602067e906e6d88
and 30c869b87739b56280daca3cd44b0588144747b7
|
|
|
|
|
| |
This is the my_popen_list counterpart of
c6fe5b981b942ddabb23ed4b7602067e906e6d88
|
|
|
|
|
|
|
| |
* Fixed POD issues.
* Fixed spelling.
* Removed most of the templating stuff; only the Module List and
Acknowledgment are left -- they will be done at the day of the release.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 2cdf406a a lot of file descriptors are opened close-on-exec,
including the pipe that is passed to the child process in a pipe-open.
This is usually fine because a dup2 follows to rename that handle to
stdin/stdout that will set the inherit-on-exec. However, if the pipe
descriptor already has the right value, for example because stdin was
closed, then no dup2 happens and hence it's still marked as
close-on-exec right when we want to perform an exec.
This patch explicitly marks such a handle as inherit-on-exec, to ensure
it will be open for the child process.
|
|
|
|
|
|
|
| |
The test within the SKIP block expects $res to be undef, but the 'skip'
condition itself expects it to be defined and numeric. So we were
getting an uninitialized value warning. In 'skip' condition, test for
definedness before numeric comparison.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests where we write a string larger than the pipe size to
a pipe hang on 15.6.0, while they seem to work on Darwin 17.7.0.
So we will skip these tests on Darwin, if the major version is
less than 16. (We may adjust this is we have more reports on
which versions between 15.6.0 and 17.7.0 success/fail).
Note that the tests hang even if we send a string of 512 characters,
which is much, much smaller than the actual size of the string in
the test.
|
|
|
|
| |
Adds USE_THREAD_SAFE_LOCALE
|
|
|
|
|
|
|
|
|
|
|
| |
This script is supposed to exercise the error handling callback
mechanism in gdbm, by triggering an error by surreptitiously closing
the file handle which gdbm has opened.
However, this doesn't trigger an error in newer releases of the gdbm
library, which uses mmap() rather than write() etc. In fact I can't see
any way of triggering an error: so just skip the relevant tests if we
can't trigger a failure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Processing two digits at a time results in noticeable performance
improvement for larger numbers.
The previous version of the function was being automatically inlined
by gcc because of its small size. It's no longer the case so I had to
use PERL_STATIC_INLINE.
I have marked the UV branch as UNLIKELY because UVs are *much* rarer
than IVs.
[perl #133691]
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
Previously, %array was used which was confusing.
|
| |
|
|
|
|
| |
Prior to this commit, it returned TRUE if the input was 0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are only three valid numbers in Computer Science: 0, 1, and "as
many as you like". 256 is not therefore a valid number, and its use
should be commented, or better, a mnemonic used instead.
These uses were spotted by lgtm as being unnecessary, and some people
were confused as to their purpose. This commit changes the 256, to in
one case, a sizeof() that indicates its a guard against going outside
the array bounds of that data structure. And in the 2nd case, it
verifies that it fits inside the space allotted to a function parameter.
A comment helps clarify that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous two commits fixed bugs where it would be possible during
optimization to join two EXACTFish nodes together, and the result would
not work properly with LATIN SMALL LETTER SHARP S. But by doing so,
the commits caused all non-UTF-8 EXACTFU nodes that begin or end with
[Ss] from being trieable.
This commit changes things so that the only the ones that are
non-trieable are the ones that, when joined, have the sequence [Ss][Ss]
in them. To do so, I created three new node types that indicate if the
node begins with [Ss] or ends with them, or both. These preclude having
to examine the node contents at joining to determine this. And since
there are plenty of node types available, it seemed the best choice.
But other options would be available should we run out of nodes.
Examining the first and final characters of a node is not expensive, for
example.
|
|
|
|
|
|
|
|
|
|
|
| |
This is defensive coding. The previous commit changed things so under
/di a node ending in [Ss] doesn't get made an EXACTFU. This commit does
the same for nodes that begin with [Ss]. This isn't actually necessary
as one needs two EXACTFU nodes in a row for the problem to occur, and
the previous commit appears to remove the possibility for the first node
being an EXACTFU. But I'm leery of relying on this. So this commit
makes sure that a node beginning with 'S' or 's' under /di remains
EXACTF
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit only nodes that filled fully were guaranteed not to
be upgraded to EXACTFU.
EXACTF nodes are used when /d rules are to be used unless the string
being matched against is in UTF-8. EXACTFU nodes are used when the /u
rules are to be used always. If the node contains only characters whose
interpretation is the same under /d and /u, both node types behave
identically, and so either can be used. EXACTFU nodes are preferred
because they are trie-able, and otherwise faster at runtime due to not
having to check the UTF-8ness of the target string. The pattern
compilation uses an EXACTFU node when possible, over an EXACTF node.
The sequences 'ss', 'SS', 'Ss', 'sS' are very tricky, for several
reasons. For this commit, the trickiness lies in the fact that they are
the only sequences where both the pattern and target string aren't in
UTF-8, and what matches under /ui rules differs from what matches under
/di. (There are various single characters that match differently, but
this is the only sequence whose individual components match the same,
but the sequence as a whole matches differently.)
The code has long taken special care for these sequences, but overlooked
two fairly obscure cases where it matters. This commit addresses one of
those cases; the next commit, the other.
Because these are sequences, it might be possible for it to be split
across two EXACTFish nodes, so that the first 's' or 'S' is the last
thing in the first node, and the second 's' or 'S' is the first thing in
the second. Should these nodes get joined during optimization, they
form the sequence. The code has long recognized this possibility if the
first node gets filled up, necessitating a split, and it doesn't make
the first node EXACTFU if it ends in 's' or 'S'. But we don't fill
those nodes totally completely, and optimization can join two together.
Future commits in the pipeline will join nodes in more cases during
optimization, and so, we need to not create an EXACTFU for trailing 's'
or 'S' always, not just if the first node fills up. This commit moves
the code that accomplishes this so it always gets executed at node end
of /di nodes, instead of previously only getting executed when the node
fills.
|
|
|
|
|
| |
By using a macro with a slightly different API, we don't have to mess
with the parse pointer.
|
|
|
|
|
|
|
|
|
| |
The optimization phase of regular expression pattern compilation looks
for adjacent EXACTish nodes and joins them if they are the same flavor
of EXACT. Commits a9f8c7ac75c364c3e05305718f38c5f8ccd935d8 and
f6b4b99d2e584fbcd85eeed475eea10b87858e54 introduced two new nodes
that are so close to existing flavors that they are joinable with their
respective flavor. This commit does that.
|
|
|
|
|
| |
This is in preparation for making the conditional more complicated than
can be easily done in the condition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previous commits in 5.29 have removed all but two calls to this
function, and the remaining ones take radically different paths in it,
with very little common code. It simplifies things if we expand each
call to the code that gets evaluated. This commit does one call.
Changing the other usage is deferred until a later commit.
The need for an #ifdef is removed by adding a flag and setting it in an
existing #ifdef.
|
|
|
|
|
|
| |
Beyond that, I agree with this branch
Signed-off-by: James E Keenan <jkeenan@cpan.org>
|