| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
cc76b5cc1552a605 added all 3 functions to the API, but declared prototypes
with const U32 flags, whilst the definitions had that parameter non-const.
Some compilers issue warnings about this inconsistency.
|
| | |
|
| |
|
|
|
|
|
| |
Commit 3c78429c102e0fe2ad30c60dfe52636b6071ef19 introduced a new test
that constructed and then evaled a very long string. Make that string less
long, as evaling it was consuming 100Mb on my debugging build, and a
smaller string still exercises the behaviour (i.e. fails on older perls).
|
| |
|
|
|
|
|
| |
This will display the release date of a given perl release.
If no perl release is specified, will list all perl releases
and release dates.
|
| |
|
|
| |
Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Long blocks of code that include logical or loop ops (i.e. those with
multiple 'branches' of ops, such as op_other, op_redo etc) cause
Perl_rpeep to recurse deeply and eventaully SEGV.
For example this crashes, due to the ENTERLOOP:
eval ("{\$x = 1 }\n" x 10000)
The deep recursion happens because the processing of the entire rest of
the code occurs in within the nested call. For example in the code
A && B; C; D; E;
the ops are structured as
A -> AND -> C -> D -> E
\ /
B
where AND->op_next points to C, while AND->op_other points to B.
rpeep() would normally process each op in the op_next sequence in turn
(i.e. A/AND/C/D/E), but when it reaches AND, it recursively calls
rpeep(B), which happens to then process B/C/D/E. Finally it returns,
and the parent rpeep processes C, finds it's already done, and exits.
Clearly, if C,D,E etc also contain conditional/loop ops, then the
recursion level gradually stacks up.
The fix for this is to add a small deferred queue to rpeep().
Whenever rpeep wants to recurse with op_other or op_lastop etc,
it instead adds it to the deferred queue. Only if the queue is full is
rpeep actually called. The hope is that by deferring, when we do
eventually process it, enough of the main op_next chain has already been
processed to ensure that the child rpeep returns very early.
In the example above, processing of AND causes B to be added to the queue,
and the main rpeep process continues processing C, D etc. Sometime later,
the queue becomes full and B is processed via a recursive call to rpeep.
B is processed, and op_next is followed to C, but C is marked as already
processed, so the child rpeep returns almost immediately.
For LOOP ops, I've stopped following op_redoop and op_nextop, since
AFAIKT the ops these point to will also be reachable vie op_next anyway.
op_lastop is the exception; in while(1){..} only op_lastop points to the
rest of the code block.
Note that this commit doesn't guarantee only shallow recursion, it just
makes deep recursion fairly unlikely.
Note also that this commit causes the order of the processing of op_next
chains to be altered; this can affect the ordering of compiler warnings
and fatal messages among potentially other things.
|
| |
|
|
|
| |
This is needed on Win32 since cc76b5cc1552a605, which make Perl_pad_setsv part
of the public API, and thereby exported for the first time.
|
| |
|
|
|
|
| |
While this may be bending over backwards, this avoids causing problems
for the Perl compiler suite and also for various CPAN modules that use
A, B and C packages for testing.
|
| | |
|
| | |
|
| |
|
|
|
| |
gimme is being set by POPBLOCK, but otherwise unused. PERL_UNUSED_VAR stops the
warning gcc generates for that.
|
| | |
|
| |
|
|
|
| |
All it does is cause warnings on recent systems with that header installed. It's
required for some variants of FreeBSD only.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
The series of commits in this branch add pad functions to the API and
make the pad fully UTF8-aware.
Previously, ‘use utf8; my $фу’ used to store raw UTF8 bytes in the
pad, without marking them as such. So things sort of worked ‘by
accident’.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Plus the test case from t/run/fresh_perl.t, but in UTF-8,
in t/op/fresh_perl_utf8.t
That file currently has only that test, but I intend to
port others from fresh_perl.t to test clean stashes/GVs.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
both sides, which isn't required, but may be more efficient than leaving it to the comparison function.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
global flag.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
Move several pad functions into the core API. Document the pad
functions more consistently for perlapi. Fix the interface issues
around delimitation of lexical variable names, providing _pvn, _pvs,
_pv, and _sv forms of pad_add_name and pad_findmy.
|
| |
|
|
| |
In win32/pod.mak, at least.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is thanks to James Keenan's work! Finally!
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Much of ExtUtils::ParseXS was rewritten and cleaned up.
It has been made somewhat more extensible and now finally
uses strictures.
The logic for parsing, merging, and dumping XS typemaps was extracted
from ExtUtils::ParseXS into a module of its own, ExtUtils::Typemaps.
ExtUtils::Typemaps offers an interface to typemap handling outside of
the scope of the XS compiler itself.
As a first use case of the improved API an extensibility, typemaps can now
be included inline into XS code with a HEREDOC-like syntax:
TYPEMAP: <<END_TYPEMAP
MyType T_IV
END_TYPEMAP
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
It can be used for embedding typemaps in XS code. Very convenient
when generating XS!
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
My fault for botching this up originally, sorry.
|
| | | |
|
| | | |
|
| | | |
|
