| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Like regen/mk_invlists.pl, if any of various Unicode-related files
change, we can't rely on the generated file remaining unchanged.
|
| |
|
|
| |
If mktables changes, the input data for this may also change.
|
| |
|
|
|
|
|
|
| |
Like the previous commit, this script may be called before mktables.lst
exists, and we can't generate mktables.lst without this script
executing to completion. The missing file is only used to determine if
something has changed that we would need to recompile for so this script
can run faster next time it is called.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regen_lib now has the capability of calculating a digest for various
files passed to it, and saving those values in the generated output
file. The passed in files are supposed to be the sources of the
generated file, so that on future regen runs, if no digest value has
changed, there should be no need to actually do the (potentially slow)
regen.
When bootstrapping up a perl, not everything may have been built before
a regen is attempted. This was dieing under those conditions,
preventing the build from happening. Thus we come to a dead-end.
This commit causes a random digest to be generated for a source file
that doesn't (yet) exist, instead of dieing. That means that the build
can continue, and the source should be generated at some point in
it. The random digest is not going to match the real one, so the next
time the regen happens, it will signal that things need to be rebuilt,
and then the actual digest of the source will be calculated and
stored.
Having the fake digest be a random number makes sure that, should the
missing file remain missing, that the regen will continue to rebuild
things each time. So, if someone carelessly commits the result without
realizing there is an empty source, the Porting tests will fail, drawing
attention to the problem.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several /lib .pm's have the same code which is complicated enough to
warrant being placed in a shared function. This commit creates a .pm
to be used by these .pm's.
This implements the perhaps archaic 'Meta' notation wherein characters
above 0x7f are displayed as M- plus the ASCII-range character derived by
looking at only the lower 7 bits of the upper range one. There are
problems with this, in that a literal control character can be in the
string, whereas it is trying to get rid of control characters. But I
left it to work as-is, just centralizing the code.
On EBCDIC platforms this notation makes no sense because the bit
patterns are all mixed up about having the upper bit set. So this
commit fixes things on these platforms, so these are changed to
\x{...}. No literal control characters are emitted.
Another potential problem is that characters above 0xFF are passed
through, unchanged. But again, I let the existing behavior stand.
|
| |
|
|
|
|
|
|
|
| |
This is to prevent a conflict showing up on z/OS (os390) because this
file's name is the same as one in /ext, and there are functions
cross-referenced between them, and the loader on that platform
can't deal with this.
See http://nntp.perl.org/group/perl.perl5.porters/226612
|
| |
|
|
| |
Hence we need to ensure that they are cleaned up.
|
| |
|
|
|
| |
In text, formerly rendered as: ("$/ = """)
Now rendered as: ("$/ = ''") which is a tad less confusing
|
| |
|
|
|
| |
These require changes to Encode which are not planned
to be put in v5.22
|
| |
|
|
|
| |
There are still a few failures that are skipped and should be looked at
in v5.23.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When smartmatch is matching a pattern against something, it was
failing to do appropriate PUTBACK and SPAGAIN's before calling
matcher_matches_sv() (which pushes an arg an calls pp_match()).
If the stack was almost full, the extra push in matcher_matches_sv()
could cause a stack realloc, which would then be ignored when
pp_smartmatch() returned, setting PL_stack_sp to point to the old (freed)
stack.
Adding SPAGAIN ensures that PL_stack_sp points to the new stack, while
PUTBACK causes PL_stack_sp to no longer see the two args to pp_smartmatch,
so the PUSH in matcher_matches_sv() pushes the SV us9ng ones of two two
reclaimed slots, so the stack won't re-alloc anyway.
Thus by doing the "right thing" with both PUTBACK and SPAGAIN, we
doubly ensure that PL_stack_sp will always be right.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the list variant of the x operator, the overflow detection code
doesn't always work, resulting in the stack not being extended enough.
There are two places where an overflow could occur: calculating how
many stack items to extend by (items * count), and passing to repeatcpy()
how many bytes to copy 'items' SV pointers (items * sizeof(const SV *)).
The overflow detection was generally a mess; checking for overflow
using a value (max) that may have already overflown; checking whether
'max' had overflown incorrectly, and not checking (items * sizeof(const SV
*) at all (perhaps hoping that the other checks would be a superset of
this).
Also, some of the vars were still I32s; promote to 64-bit capable types.
Finally, the signature of Perl_repeatcpy() still has an I32 len;
that really should be changed to IV at some point; but for now I've just
ensured that the callers (list 'x' and scalar 'x') don't wrap.
I haven't put in a check for the only other core caller of repeatcpy(),
S_study_chunk(), since that would only become an issue compiling a pattern
with a fixed or floating substr within it of length > 2**31.
|
| |
|
|
| |
This macro is private to op.c, and has an overly generic name.
|
| |
|
|
|
|
|
|
|
|
|
| |
The OpSIBLING() macro and op_sibling_splice() are a higher-level
way of manipulating optrees that ensure portability in the face of
PERL_OP_PARENT etc.
This commit also helps with the lofty goal of nothing outside of op.c
directly accessing the op_sibling field.
This is a follow-on/improvement to bac7a184cda7b.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If s;; gobbles up the implicit semicolon that is tacked on to the end
of the file, it can confuse the here-doc parser into thinking it is
inside a string eval, because there is no file handle. We need to
check for that possibility where the assertion was failing.
|
| |
|
|
| |
Outdent code that the previous commit removed the surrounding block from
|
| |
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, the regex compiler was relying on the lexer to do
the translation from Unicode to native for \N{...} constructs, where it
was simpler to do. However, when the pattern is a single-quoted string,
it is passed unchanged to the regex compiler, and did not work. Fixing
it required some refactoring, though it led to a clean API in a static
function.
This was spotted by Father Chrysostomos.
|
| | |
|
| | |
|
| |
|
|
|
| |
The previous commit removed a surrounding block. outdent
correspondingly
|
| |
|
|
|
| |
This collapses two pieces of code into one. It isn't necessary to have
an ASCII version vs an EBCDIC version.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By this simple change, we can avoid printing all controls except \c?.
On ASCII platforms the remaining control is DEL, which is handled above.
On EBCDIC platforms, \c? remains a problem.
But it isn't clear what to do about this anyway, as the module
interprets ^D, ^H, ^U specially as if they were typed from the keyboard,
and expects the keyboard to transmit them in a particular way, which may
not be valid for EBCDIC. No tests fail, so fixing this will have to
wait for tuits or field complaints.
|
| | |
|
| | |
|
| |
|
|
|
| |
This depends on Unicode::Collate, which is not yet working properly in
EBCDIC
|
| |
|
|
|
| |
This also fixed a bug which hasn't shown up in the tests, in that it
uses 'char' where it should be 'U8'.
|
| |
|
|
|
|
|
| |
\b{} and \B{} are valid in UTF-8 locales, as all the Unicode rules
apply. Prior to this patch a warning was raised under some
circumstances. The warning text was generalized to handle both \b and
\B cases. The original text was only just added, in 5.21.9.
|
| |
|
|
|
| |
This adds anchors to a pattern. I discovered while changing things that
it still passed when broken
|
| | |
|
| |
|
|
|
|
|
|
| |
Commit 31ac59b61698e704b64192de74793793f4b5b0c0 inadvertently changed
the behavior of the pure perl version of Data::Dumper. If a newline is
the sole character in something being dumped with useqq, it no longer
got translated into a \n sequence and was output raw. This was due to
the regex matching of \n at beginning and ends of strings.
|
| |
|
|
|
|
|
|
|
|
| |
On some platforms, t/op/dump.t produces extraneous (and scary)
sh: line 1: 17605 Aborted (core dumped)
style messages on stderr.
Do a fork in each test to avoid this.
|
| |
|
|
|
|
|
| |
A recent commit added a label, plus a "goto that label" only in the EBCDIC
case. On "normal" builds, the compiler complained about an unused label.
Also, indent the recent '#ifdef EBCDIC' correctly.
|
| |
|
|
|
|
|
|
| |
S_grok_bslash_o() and S_grok_bslash_x() scan \o{...} and \x{...} in a
string, and return a UV codepoint. Some callers assume that if that
codepoint is converted into a series of utf8 bytes and re-inserted into
the string, that it will tale up less space than the original "\x{...}"
sequence. Add asserts that this is indeed so.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The context gets recorded on the context stack when a loop is entered.
That context is then used at loop exit when handling the stack.
In the case of foreach, the context applied to the stack was taken
from the enteriter op. But the enteriter op was always getting list
context applied. That meant that foreach(@empty_array){} in scalar
context would push nothing on to the stack, causing a subsequent stack
read to look one item too far to the left, either reading the wrong
thing, or causing a stack underflow (even a crash). The clearest bug
resulting from it:
$ ./miniperl -le 'push @_, 1, 2, 3, scalar do { for(@x){} } + 1, 4, 5, 6; print "@_"'
1 2 4 4 5 6
instead of 1 2 3 1 4 5 6.
We do need to apply list context to make sure the items iterated over
are evaluated in list context. But we need to apply it *only* to
those (expr in newFOROP), not the the outer enteriter op. That op’s
context should be left unset here, so that the calling context will be
applied to it.
This bug goes back at least to perl 5.000.
|
| |
|
|
|
|
|
| |
PL is reserved for global variables. These are enums and static
variable names introduced for handling /\b{...}/
See <20150311150610.GN28599@iabyn.com> and follow up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some extensions hints files (B, Digest-MD5, PerlIO-via) forcefully
overwrite OPTIMIZE in order to work around compiler mishaps with high level
optimizations. However, this loses whatever extra flags are listed in
OPTIMIZE, such as compiler warnings flags or PERL_POISON, and makes them
difficult to run under a debugger since a minimal level of optimization
(usually -O1) is always enforced. This has became visible recently with
new XS handshake facility.
Instead, we chose to just follow Storable's strategy of lowering the
optimization level with a substitution, while keeping all the other flags
untouched. If other compiler flags are deemed problematic (such as
-mcpu/-march on gcc), they ought to be addressed separately.
Only B and PerlIO-via hints files are fixed by this change. The case of
Digest-MD5 will be addressed on the CPAN.
This fixes [RT #124038].
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Turning off -b (ignore whitespace) revealed a whitespace difference lurking
in blead's copy of a NEXT test file, which there is no need for.
Turning on --binary revealed EOL differences in numerous Win32API-File
files. Hopefully a future CPAN release will fix those since the files in
its GitHub repo match blead as far as EOLs go already.
|
| |
|
|
|
|
|
| |
...at least for now.
This reverts commits 0d314ba30623b19c36dfc97ac4b6ecb94cb406f4
and ce3778a3796be3e4604ed9b3671ea624c5affe0b.
|
