| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
and space for readability
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__DATA__ is supposed to stuff the rest of the file into the DATA han-
dle belonging to the package in scope where __DATA__ is encountered.
That means this should always print 123:
print <DATA>;
__DATA__
123
But it fails if the package has been renamed through glob assignment:
package foo;
BEGIN{*foo::=*bar::}
print <DATA>;
__DATA__
123
(Prints nothing.)
The code for stuffing DATA was stringifying the package and then look-
ing it up again. Not only is it more correct to avoid the stringifi-
cation, but faster, too.
|
| |
|
|
|
| |
Module::Build reports that it's deprecated from core from version 5.19.0,
but this information was missing from Module::CoreList.
|
| |
|
|
|
|
| |
Calling SvNV on an SV that is IOK is unnecessary, and results in an
extra function call if the SV is not NOKp. If an NV is out of range
and has been used as an int, it will be IOKp but not IOK.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Maybe we should extend it at some point to run things through
splain and see whether there is a match.
|
| |
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the rest of ticket #119161.
The range operator uses IVs internally to hold the current value for
integer ranges. It already checks that the arguments are within the
IV range and croaks otherwise. However, on 32-bit platforms with
64-bit integers, the different between the range’s endpoints can
exceed the maximum allowed memory allocation. This resulted in a
crash for 1..2**31, because EXTEND was passed a value which, when
cast to SSize_t, became -1, resulting in no reallocation. Then
pp_flop proceeded to write past the end of the stack.
No tests are included in this commit, as 1..2**31 could give three
different results depending on the platform.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I am referring to what is usually known simply as The Stack.)
This partially fixes #119161.
By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all. Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.
I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for #119161.
On 64-bit platforms, I32 is too small to hold offsets into a stack
that can grow larger than I32_MAX. What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices, corrupting memory, and causing crashes.
With this commit, ()=1..1000000000000 stops crashing immediately.
Instead, it gobbles up all your memory first, and then, if your com-
puter still survives, crashes. The second crash happesn bcause of
a similar bug with the argument stack, which the next commit will
take care of.
|
| |
|
|
|
|
|
|
|
|
|
| |
Regexp is a built-in class for which no module is normally loaded, so it
can't provide its own CARP_TRACE method. Carp must therefore supply it.
The method formats a regexp reference as a qr() expression as much as
possible. Like string arg formatting, it uses \x{} escapes for literal
characters that are not ASCII printable, and it truncates according
to $Carp::MaxArgLen. The truncation happens at a different stage of
processing from its position in string arg formatting, because regexp
stringification presents an already-partly-escaped form of the regexp.
|
| |
|
|
|
| |
Debugging code was left in the version of Carp's string arg formatting
that handles upgraded strings on older perls.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, an upgraded string argument would be wrapped in quote
characters but have all of its characters represented literally in
the stack trace, including control characters. Also, the escaping of
unprintable characters for downgraded string arguments wasn't consistent
with Perl syntax: it used \x{} escapes inside single quotes.
The new way is that string arguments (except those that look numeric)
are represented as double-quoted strings, using correct Perl syntax.
Characters outside the ASCII printable range always get \x{} escaping,
whether the string is upgraded or downgraded. ASCII printables that
require backslash escaping get it. Where an argument is truncated
due to length, the added ellipsis appears outside the double quotes,
to avoid ambiguity with a string that contains actual dots.
Implementing this is complicated by problems with applying regexps to
upgraded strings, which are particularly a problem in the constrained
environment in which Carp must run. This has previously inhibited us
from implementing correct handling of upgraded strings. The problems
were all resolved in Perl 5.13.11, so from there on we can just use the
simple regexp implementation. On older Perls upgraded strings now get
the same treatment, but implemented in a less efficient manner that does
not use regexps.
Non-string arguments, most notably references, are now are not represented
as quoted strings. The overload::StrVal() representation is safely
distinct from other argument representations. This in particular allows
distinguishing between an argument that is a reference and an argument
that is the result of stringifying a reference.
|
| |
|
|
|
|
| |
The default subdirs rule creates a race condition with the rule that
Makefile.PL explicitly adds to generate libsdbm.a, which can cause parallel
makes to fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit ce0d59fdd1c started using NULL to indicate nonexistent array
elements. Since pads are AVs, they are filled with NULLs initially,
rather than &PL_sv_undef.
For ‘our’ vars, the pad entry is never actually touched. Only one
piece of code was inspecting it, namely S_cv_clone_pad. &PL_sv_undef
just happens to pass the checks that make sure the var is not stale.
However, we really should not be checking that at all if this is an
‘our’ var.
Even if we change ‘our’ vars back to having a &PL_sv_undef pad
entry, this fix should stay, as it makes the code clearer and makes
S_cv_clone_pad more robust.
|
| |
|
|
|
|
|
|
|
|
|
| |
I would have to change the header to something other than
‘perldelta’, even though that is what the final document
will have.
I would also have to start adding modules to the known modules
list which will not have to be there in the final release.
That is more work than necessary, so just skip this file for now.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
so that we can track these all in one spot and close the various RT
tickets as we go.
I am only listing ‘high-profile’ modules, meaning those that have
at least 5 dependents (an arbitrary number picked by Jesse Vincent
some time ago).
|
| |
|
|
| |
just the template for now
|
| |
|
|
|
| |
[rt.cpan.org #76167] For tests not relating to the B module, avoid using
"B" as a package name.
|
| |
|
|
|
|
|
| |
There's an old test to check that Carp doesn't vivify B:: despite
attempting to use B::svref_2object(). Turn this into the same kind of
test now used for overload::StrVal() and utf8::downgrade(), testing more
cleanly for stash vivification and also testing for GV vivification.
|
| |
|
|
|
|
| |
This commit adds #if's to cause locale handling code to compile on
platforms that don't have full-featured locale handling. The commits
mentioned in the ticket did not adequately cover these situations.
|
| |
|
|
|
|
| |
This call to regclass_swash() is not using its return value, so don't
store it in a variable that is otherwise unused, which causes some
compilers to complain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Carp avoids autovivifying stashes when seeing whether a sub like
utf8::is_utf8 or overload::StrVal exists.
Its logic was slightly faulty, in that it did not take into account
that the existence of $::{"utf8::"} does not indicate the presence
of a typeglob in that element. It could have been created due to
autovivification. It also failed to take into account that $utf8::’s
HASH slot might be empty. This would result in death.
In fixing this, I moved the common logic into a single function
and also took the opportunity to avoid multiple hash lookups in
a row.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These two code paths are now nearly identical. However, one uses s as
its cursor; the other uses d therefor while using s to remember the
previous position. If we switch the uses of d and s, then outside of
PL_madskills we don’t even need to set d.
|
| |
|
|
|
|
|
|
|
|
|
| |
This ‘if(){’ has been commented out since it was added in 5db068806.
Presumably the intent was to make the special mad code specific to
PL_madskills at some point and have mad builds running without
PL_madskills follow the same code as regular builds (the *s = '\0' and
PL_bufend assignments).
Since then, though, the standard code has changed to match the mad
code. The next commit will merge them.
|
| |
|
|
|
|
|
|
|
| |
This affects only mad builds. The line number after
nullary_keyword_such_as_time
;
was off by one.
|
| |\
| |
| |
| |
| | |
The Makefile.ce PV change was split off into an update of
bump-perl-version
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
configpm
- when debugging configpm, Config.pm is already loaded, so the alternate
Config.pm for CE isn't loaded, warn about the problem and delete the
native Config.pm to allow the cross Config.pm to be loaded
win32/Makefile.cd
- better build product cleanup, copy from the win32 makefile
- disable a bunch of module that dont/dont yet build on CE
- debugging configpm required a shortcut to make it easier to run in
isolation
- fix the defines that wind up in the cross Config.pm
- add -GS- to disable the MS Security Cookie feature on MSVC for ARM >=14
compilers, this stops a .lib linking error, security cookie overhead
isnt needed for a very space limited device
sdsdkenv.bat is the file I use to set env vars to compile for WM since
starting in SmartDevices SDK, there is no equivelent of vcvarsall.bat
for makefile building, there was a vcvarsall.bat equivelent in EVC4 tho
MSVC for non Intel CPUs sometimes isn't named cl.exe, fix config_sh.PL to
deal with it
how to compile CE Perl, some steps involving celib and MS SDKs not included
and 2 patches to CPAN modules, Socket and MakeMaker, are not in this commit
but they are required to build CE Perl
-in a Win32 x86/x64 command prompt do a "nmake all" to make a Desktop Perl
-then in a WinCE build env command prompt do a "nmake -f makefile.ce all"
-/xlib will have all your XS DLLs and PM files, /win32/$(MACHINE) will
have perl519.dll and perl.exe
Tony Cook: update MANIFEST
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2179133 (in 5.19.2) introduced this line number bug when it
modified the parser to look past newlines when searching for => after
a keyword:
$ perl5.19.3
1 unless
1;
warn;
^D
Warning: something's wrong at - line 2.
The warning should say line 3, not 2.
Before 2179133, the parser’s line-reading algorithm work strictly in
two modes: From a file, one line would be read into PL_linestr at a
time. In a string eval, PL_linestr would contain all the code.
To be able to look past a newline to find => after a keyword, the
parser’s former mode had to be adjusted:
• It has to be possible to append more lines of input to the buffer
without incrementing the line number.
• When reading from a filehandle, the lexer should not assume when it
sees "\n" that it has reached the end of the buffer.
Commit 2179133 did those two things.
It did not, however, make the lexer increment the line number when
encountering a newline in the middle of it (when reading from a han-
dle; string eval follows a different code path).
Fixing it to do that requires that lex_start be adjusted, too. When
lexing begins, PL_linestr is set to "\n;" when there is no string to
eval. This worked for file handles because the lexer, on seeing the
\n, would ignore the semicolon.
Now that it no longer ignores the semicolon, it will end up incre-
mented the line number erroneously at the outset, so set the buffer
to just "\n" instead.
In one place (skipspace2), the mad-specific code was setting PL_bufptr
to point at its previous location after calling skipspace. skipspace
sets it to point after the newline to prevent incline() from being
called a second time for the same newline. But this is exactly what
happens if skipspace2 resets PL_bufptr. The callers of skipspace2
apparently don’t depend on this, so we can remove it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since bfloor() and bceil() exist, add bint() for completeness. As with
bfloor() and bceil(), bint() does not change the object class. This is
unlike as_int(), which converts the object to a Math::BigInt.
Rename bint() subroutine in the example section to bigint() to avoid
confusion with the new method bint().
Add tests for bint().
Add a little more precise documentation of bfloor() and bceil().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on work done by Peter John Acklam, differences from his original
patch:
- links to items (which have been corrected by others) have been retained
- unnecessary conversion of < and > to E<lt> and E<gt> has been skipped.
- =over N has been converted to =over
- adjusted white-space in many places to avoid hitting column 80 in
perldoc for verbatim text
|
