summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Perlhist: Date of the 5.29.6 release.v5.29.6Abigail2018-12-181-0/+1
|
* Perlhist: Fix the release dates for 5.29.[345].Abigail2018-12-181-3/+3
| | | | These releases were made in 2018, not 2019.
* Perldelta: Don't put a reference to an RT ticket in its own paragraph.Abigail2018-12-181-1/+0
|
* Perldelta: Linkefy references to Perl RT tickets in the Modules section.Abigail2018-12-181-5/+9
|
* Errata in perldelta.Abigail2018-12-181-13/+19
| | | | | | | | 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.
* Perldelta: New/Updated Modules for 5.29.6Abigail2018-12-181-41/+9
|
* Perldelta: Acknowledgements for 5.29.6.Abigail2018-12-181-2/+26
|
* Update Module::CoreList for 5.29.6Abigail2018-12-183-7/+96
|
* perldelta notes for Storable, EU::PXS, and sort the modules.Tony Cook2018-12-171-3/+22
|
* perldelta for f75dfdbdb9d5Tony Cook2018-12-171-0/+5
|
* (perl #133673) disable the File::Find nlink optimization by defaultTony Cook2018-12-171-31/+9
| | | | This will also fix 128894 and 126144.
* regcomp.c: Tighten embedded patterns in regex setsKarl Williamson2018-12-162-13/+10
| | | | | | | 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.
* perlrecharclass: Clarify embedding in regex setsKarl Williamson2018-12-161-15/+15
|
* perlre: Italicize variable textKarl Williamson2018-12-161-1/+1
|
* Perldelta: Clarify when CVE-2018-18312 was fixed.Abigail2018-12-161-1/+2
| | | | | | | 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.
* Correct previous perldelta entry, and add a testKarl Williamson2018-12-163-5/+24
| | | | | | | | | 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/
* Add perldelta entry for pipe open fixesLeon Timmermans2018-12-161-0/+8
| | | | | This covers c6fe5b981b942ddabb23ed4b7602067e906e6d88 and 30c869b87739b56280daca3cd44b0588144747b7
* Always mark pipe in list pipe-open as inherit-on-execLeon Timmermans2018-12-161-1/+3
| | | | | This is the my_popen_list counterpart of c6fe5b981b942ddabb23ed4b7602067e906e6d88
* Get pod/perldelta in shape.Abigail2018-12-161-237/+10
| | | | | | | * 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.
* Perldelta entries for 5.29.6.Abigail2018-12-161-14/+101
|
* Always mark pipe in pipe-open as inherit-on-execLeon Timmermans2018-12-151-1/+3
| | | | | | | | | | | | | 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.
* Avoid "Use of uninitialized value $res in numeric eq (==)" warningJames E Keenan2018-12-151-1/+1
| | | | | | | 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.
* Correct spelling error in 'skip' messageJames E Keenan2018-12-151-1/+1
|
* t/io/eintr.t: Skip some tests on pre-16 Darwin.Abigail2018-12-151-55/+62
| | | | | | | | | | | | 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.
* Update Config::Perl::V to version 0.31H.Merijn Brand2018-12-1522-23/+30
| | | | Adds USE_THREAD_SAFE_LOCALE
* ext/GDBM_File/t/fatal.t: handle non-fatalityDavid Mitchell2018-12-141-9/+26
| | | | | | | | | | | 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.
* S_uiv_2buf: faster integer stringification algorithmTomasz Konojacki2018-12-123-12/+71
| | | | | | | | | | | | | | 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]
* (perl #133667) documentation improvements for the POSIX moduleTony Cook2018-12-121-2/+5
|
* we don't need ext/POSIX/t/math.t +xTony Cook2018-12-121-0/+0
|
* (perl #133582) make C99 functions available for Win32 Mingw buildsTony Cook2018-12-126-110/+114
|\
| * math.t - support C99 math for mingwsisyphus2018-12-111-1/+6
| |
| * config_sh.PL - support C99 math for mingwsisyphus2018-12-111-9/+8
| |
| * config_H.gc - support C99 math for mingwsisyphus2018-12-111-49/+49
| |
| * config.gc - support C99 math for mingwsisyphus2018-12-111-49/+49
| |
| * POSIX.xs - support C99 math for mingwsisyphus2018-12-111-1/+1
| |
| * perl.h - support C99 math for mingwsisyphus2018-12-111-1/+1
|/
* Call a hash %hash in the documentationE. Choroba2018-12-111-6/+6
| | | | Previously, %array was used which was confusing.
* (perl #133708) remove build-time probing for stack limits for StorableTony Cook2018-12-1011-167/+36
|
* handy.h: Fix definition of isPOWER_OF_2()Karl Williamson2018-12-091-1/+1
| | | | Prior to this commit, it returned TRUE if the input was 0.
* regcomp.h: Fix typo in commentKarl Williamson2018-12-091-1/+1
|
* regexec.c: Use mnemonics instead of "256"Karl Williamson2018-12-072-6/+6
| | | | | | | | | | | | | 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.
* regcomp.c: Allow more EXACTFish nodes to be trieableKarl Williamson2018-12-075-140/+308
| | | | | | | | | | | | | | | | | | 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.
* regcomp.c: Make sure /di nodes begining in 's' are EXACTFKarl Williamson2018-12-071-4/+35
| | | | | | | | | | | 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
* regcomp.c: Make sure /di nodes ending in 's' are EXACTFKarl Williamson2018-12-071-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* regcomp.c: Simplify a bit of codeKarl Williamson2018-12-071-3/+3
| | | | | By using a macro with a slightly different API, we don't have to mess with the parse pointer.
* regcomp.c: Can join certain EXACTish node typesKarl Williamson2018-12-071-1/+17
| | | | | | | | | 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.
* regcomp.c: Move clause of while() conditional into loopKarl Williamson2018-12-071-3/+7
| | | | | This is in preparation for making the conditional more complicated than can be easily done in the condition.
* regcomp.c: Add assertionKarl Williamson2018-12-071-0/+3
|
* Remove one use of static functionKarl Williamson2018-12-071-15/+17
| | | | | | | | | | | 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.
* No need to convert int to long to intH.Merijn Brand2018-12-071-1/+1
| | | | | | Beyond that, I agree with this branch Signed-off-by: James E Keenan <jkeenan@cpan.org>