| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Merge a gv_fetchpvn and a gv_fetchpv. A strlen call is avoided in
gv_fetchpv, and in Perl_newXS_len_flags shorter machine code because 2
different call destinations were merged to 1, and
"GV_ADDMULTI | flags,SVt_PVCV" arguments are unconditionally executed
and are not in a branch.
|
| |
|
|
|
|
|
|
|
| |
Courtesy of the OpenVMS C compiler, which said:
SV *
^
%CC-I-MISSINGRETURN, Non-void function "Perl_sv_mortalcopy" does not contain a return statement.
at line number 1206 in file D0:[craig.blead]mathoms.c;1
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3e462cdc208 fixed bug #41530 (s/non-utf8/utf8/ was not working
properly at all) by upgrading the target and redoing the substitution
if the replacement was utf8 and the target was not.
Commit c95ca9b8cd1 fixed one problem with it calling get-magic too
many times, by checking whether the upgrade caused a string realloca-
tion and only then redoing the substitution. But it only fixed it
when magic returns a pure ASCII string.
Redoing the substitution meant going back to where the target was
initially stringified and starting again. That meant calling get-
magic again.
So in those cases where magic returned something other than a UTF8 or
pure ASCII string the substitution restarted and magic would be trig-
gered again, possibly resulting in infinite loops (because it would
have to be upgraded again, resulting a reallocation, and a restart).
This happens with:
• Latin-1 strings
• Copy-on-write non-UTF8 strings
• References that stringify without UTF8
c95ca9b8cd1 also added SvPVX without checking first that it is SvPVX-
able, so a typeglob causes an assertion failure.
It turned out that there were also two other places in pp_subst that
were calling FETCH a second time (the tests I added for the looping/
assertion bugs found this), so I changed them, too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit c72077c4fff72b66cdde1621c62fb4fd383ce093 fixed a place where
to_byte_substr() fails, but the code continued as if it had succeeded.
There is yet another place where the return is not checked. This commit
adds a check there.
However, it turns out that there is another underlying problem to
[perl #114808]. The function to_byte_substr() tries to downgrade the
substr fields in the regex program it is passed. If it fails (because
something in it is expressible only in UTF-8), it permanently changes
that field to point to PL_sv_undef, thus losing the original
information. This is fine as long as the program will be used once and
discarded. However, there are places where the program is re-used, as
in the test case introduced by this commit, and the original value has
been lost.
To solve this, this commit also changes to_byte_substr() from returning
void to instead returning bool, indicating success or failure. On
failure, the original substrs are left intact.
The calls to this function are correspondingly changed. One of them had
a trace statement when the failure happens, I reworded it to be more
general and accurate (it was slightly misleading), and added the trace
to every such place, not just the one.
In addition, I found the use of the same ternary operation in 3 or 4
consecutive lines very hard to understand; and is inefficient unless
compiled under C optimization which avoids recalculating things. So I
expanded the several nearly identical places in the code that do that so
that I could quickly see what is going on.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning appeared if the pattern contains a floating substring for
which utf8 is needed, and the target string isn't in utf8. In this
situation, downgrading the floating substring yields undef, which
triggers the warning.
Matching can't succeed in this situation, because it's impossible for
the non-utf8 target string to contain any string which needs utf8 for
its own representation. So the warning is quelled by aborting the match
early.
Anchored substrings already have a check of this form; this commit makes
the corresponding change in the floating-substring case.
|
| |
|
|
|
| |
As per precedent about 15 lines earlier in file, with respect to same
variable.
|
| |
|
|
|
|
|
|
| |
XS code doing sv_mortalcopy(sv) will expect to get a true copy, and
not a COW ‘copy’.
So make sv_mortalcopy and wrapper around the new sv_mortalcopy_flags
that passes it SV_DO_COW_SVSETSV, which is defined as 0 for XS code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was trying to figure out why Encode’s perlio.t was sometimes failing
under PERL_OLD_COPY_ON_WRITE (depending on the number of comments in
the source code, or metereological conditions).
I noticed that PerlIO::encoding assumes that the buffer passed to
the encode method will come back SvPOKp. (It accesses SvCUR without
checking any flags.)
That means it can come back as a typeglob, reference, or undefined,
and PerlIO::encoding won’t care. This can result in crashes. Assign-
ing $_[1] = *foo inside an encode method is not a smart thing to do,
but it shouldn’t crash.
PerlIO::encoding was also assuming that SvPVX would not change between
calls to encode. It is very easy to reallocate it. This means the
internal buffer used by the encoding layer (which is owned by the
SV buffer passed to the encode method) can be freed and still subse-
quently written too, which is not good.
This commit makes PerlIO::encoding force stringification of the value
returned. If it does not match its internal buffer pointers, it
resets them based on the buffer SV.
This probably makes Encode pass its tests under
PERL_OLD_COPY_ON_WRITE, but I have yet to confirm it. Encoding mod-
ules are expected to write to the buffer ($_[1] = '') in certain
cases. If COW is enabled, that would cause the buffer’s SvPVX to
point to the same string as the rhs, which would explain why the lack
of accounting for SvPVX changes caused test failures under
PERL_OLD_COPY_ON_WRITE.
|
| |
|
|
|
|
|
| |
These are surely not required by anything, and are only stub functions
anyway so can easily be provided locally by anything that really does need
them. Also hide the declarations other than when building the core itself
as per the fix for [perl #114516].
|
| |
|
|
|
|
|
|
|
|
|
| |
Archaeology tells me that it's string evals for a reason.
commit 933bc096593f55b9633fb193815ddd81d5b5ec1b
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date: Tue Nov 27 01:22:22 2001 +0000
\141 is malformed "unexpected continuation byte" in UTF-EBCDIC.
Delay the match until runtime.
|
| | |
|
| |
|
|
| |
With a small fix from committer: No use to eval {} module loading.
|
| |
|
|
|
|
|
|
| |
5.6 does not like it when a sub is declared with a prototype after a
reference to it has been taken.
5.6 does not think lowercase module names should be exempt from
reserved word warnings before ->.
|
| |
|
|
|
|
|
|
|
|
| |
We use the ;$ prototype for testing global overrides under 5.8, as it
had no _ prototype. But back then (before 5.14, in fact) ;$ did not
give a function unary precedence.
Comparing against 5.009004 in bigint scope is the same as comparing
against 5, resulting in incorrect version checks and skips being
skipped.
|
| |
|
|
|
| |
Older versions of Math::BigInt required the input to from_oct to
begin with a 0.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in <https://rt.cpan.org/Ticket/Display.html?id=79915>,
bigint.pm does not use any prototype when globally overriding hex.
This means that map { hex } ... will stop working in completely unre-
lated code if bigint happens to be loaded. (Explicit $_ will con-
tinue to work.)
I thought it would be a simple matter of adding the right prototype
depending on perl version (and inferring $_), but the basic tests
I added failed for other reasons after I fixed the prototype and
$_ handling.
It turns out this whole thing is a mess, so I have basically reimple-
mented these two overrides.
What bigint, bignum and bigrat were doing was this: In import,
*CORE::GLOBAL::hex and ::oct are assigned functions that create
Math::BigInt objects if the pragma is in effect. If import is passed
'hex' or 'oct', then the function assigned does not check the pragma
hints, but simply creates Math::BigInt objects regardless.
This means that ‘use bigrat’ stops hex() and oct() from creating
objects in ‘use bigint’ scopes, and vice versa. In fact, whichever
pragma is loaded last wins. Any scopes elsewhere in the program that
use the same pragma will have special hex() and oct() behaviour. But
the other two lowercase big* pragmata will be disabled with regard to
hex and oct.
Having ‘use bigint 'hex'’ override hex globally makes no sense to me.
I have no qualms about changing it, as it was already broken. Any
subsequent ‘use bigint;’ would turn off the global override. So now
it exports hex or oct to the calling package, just like a normal mod-
ule. You can now also call bigint::hex.
Also, in writing tests I found that oct("20") gives me 20. Apparently
this was never tested properly.
I also found notes about ‘5.9.4 or later’ when the code checked
$] > 5.009004. (Actually, in one place the code checked > 5.009003,
so I made it match, as we use the _ prototype now, which was intro-
duced in 5.9.5.) One was in the docs, so I changed it to 5.10.0,
since it is not helpful to mention dev versions. The docs were also
wrong to imply that ‘no bigint’ would countermand ‘use bigint 'hex'’.
|
| |
|
|
| |
For staying in sync with CPAN.
|
| |
|
|
|
|
| |
Karl Williamson noticed that we dont always deal with common suffixes in
the most efficient way. This change reworks how we convert a trie to an
optree so that common suffixes are always grouped together.
|
| | |
|
| |
|
|
|
| |
I inadvertently moved them inside run_tests in commit 5888debfcd,
resulting in closure warnings.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
on other OSes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applying copy-on-write to pad names when generating uninitial-
ised warnings results in modifications to SvPVX(sv) after
sv_setsv(sv,padname) affecting the pad name as well. sv_setsv_flags
with no flags avoids the COW.
Under PERL_OLD_COPY_ON_WRITE and warnings, this:
my (@ma);
$v = sin $ma[1000];
$v = sin $ma[$$];
was producing this:
$ pbpaste|./miniperl -w
Use of uninitialized value $ma[1000] in sin at - line 2.
Use of uninitialized value within $ma in sin at - line 3.
If you comment out the sceond line:
$ pbpaste|./miniperl -w
Name "main::v" used only once: possible typo at - line 3.
Use of uninitialized value within @ma in sin at - line 3.
Notice the @ma/$ma difference.
The first uninit warning was modifying the pad name.
|
| |
|
|
| |
This allows t/lib/universal.t to pass under PERL_OLD_COPY_ON_WRITE.
|
| | |
|
| |
|
|
| |
This reverts commit 34bd199a87daedeaeadd8e9ef48032c8307eaa94.
|
| | |
|
| |
|
|
|
|
|
|
| |
See <craigberry-E9C729.16313730092012@cpc2-bmly6-0-0-cust974.2-3.cable.virginmedia.com>.
Move the YYDEBUG defines in perly.c back where they were before, but
undefine YYDEBUG first. That leaves bison 2.6’s YYDEBUG defines in
perly.h harmless.
|
| |
|
|
|
|
| |
I was putting tests below run_tests by mistake. When substr_thr.t is
run, the tests below run first. Any warnings they cause will make the
no warnings tests at the top of the script fail.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I began by trying to fix the remaining issues in ticket #114410,
namely, overloading interacting badly with utf8 caching. I discovered
other bugs along the way (some of which touch on #114690 and #80190),
fixing them in the process.
The core no longer uses length magic on scalars. mg_length is depre-
cated (see its docs for why). The PERL_MAGIC_scalar vtable no longer
contains a length function, and Perl_magic_len is gone. mg_length has
been corrected always to return a byte count, as it did originally,
instead of characters for scalars without length magic and bytes
otherwise.
sv_pos_u2b and sv_len_utf8 now only store utf8 caches on non-magical
PVs. They used to cause bugs not only on tied and overloaded values,
but also typeglobs and non-overloaded references.
sv_or_pv_len_utf8 and sv_or_pv_pos_u2b are two new macros for calling
the non-_or_pv versions on muggle scalars and using the pv directly
for SvGMAGICAL scalars.
sv_len_utf8 now returns a character count, as documented, instead of
assuming that what is passed to it is utf8 (an unreliable assumption,
as the UTF8 flag is meaningful only *after* stringification, and
sv_len_utf8 stringifies).
length, pos, substr and sprintf now avoid triggering overloading or
ties too many times or reading the UTF8 flag at the wrong time, by
following one of these sequences:
If the scalar is going to be stringified:
• Call get-magic.
• Stringify the scalar in place.
• Check the UTF8 flag.
• Use the non-magical variants of the above functions:
sv_pos_u2b_flags without SV_GMAGIC, and sv_len_utf8_nomg.
If the scalar is not going to be modified:
• Call get-magic.
• Stringify the scalar without coercing it, and save the string.
• Check the UTF8 flag.
• Use sv_or_pv_ macros.
sysread, syswrite and pack no longer need to be as complicated any
more, now that sv_pos_u2b and sv_len_utf8 (and their _or_pv variants)
are more friendly, so they have been simplified.
utf8::encode now calls FETCH and STORE on tied variables. It stopped
calling fetch with the magic flags patch. It had never called STORE.
utf8::decode now calls STORE, too. It likewise had never called it.
This means it no longer preserves pos.
|
| | |
| |
| |
| |
| | |
Calling overloading multiple times can probably result in mangled
UTF8, but it is much easier just to test for the number of calls.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
sv_len_utf8 is now careful not to record caches on magical or over-
loaded scalars (any non-PV, in fact). It also returns the number of logical characters correctly, regardless of whether its input is utf8.
So we can take advantage of that to simplify pp_sysread.
For pp_syswrite, we can use sv_or_pv_len_utf8 with the existing
string buffer.
|
| | |
| |
| |
| |
| |
| |
| | |
sv_len_utf8 is now careful not to record caches on magical or over-
loaded scalars (any non-PV, in fact). It also returns the number of
logical characters correctly, regardless of whether its input is utf8.
So we can greatly simplify this code.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Assigning to a substr lvalue scalar was invoking overload too
many times if the target was a UTF8 string and the assigned sub-
string was not.
Since sv_insert_flags itself stringifies the scalar, the easiest
way to fix this is to force the target to a PV before doing any-
thing to it.
|
| | |
| |
| |
| |
| | |
This was added in commit 9bf12eaf4 to fix a crash, but it is not
necessary any more, due to changes elsewhere.
|
| | |
| |
| |
| |
| |
| | |
This was fixed in 9bf12eaf4, but apparently never tested.
It used to crash, so no is() is necessary.
|
| | | |
|
| | |
| |
| |
| |
| | |
This function always assigns to *lp twice (though indirectly the first
time). It only needs to do so once.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If it checks the UTF8 flag first, it might be looking at a stale flag,
resulting in malformed UTF8. Both tests added produced malformed utf8
strings before this commit.
Simply moving this:
if (!DO_UTF8(sv))
sv_utf8_upgrade(sv);
after the stringification is not enough to fix this, as the string
retrieved will be out of date after we do an upgrade. To avoid
stringifying twice, we use SvPV_force if there is a replacement. This
means rearranging if() blocks a little.
The use of SvPV_force also means that string overloading is no longer
called twice on the target scalar. This rearrangement also means
that targets upgraded to utf8 are no longer exempt from the refer-
ence warning. (Oh, and the test for that warning was not testing any-
thing in its no warnings test, because the target was no longer a ref-
erence; so I corrected the test.)
|
