Created by Registry Administrators on 2010-05-01 and last modified on 2015-05-06
Get this branch:
bzr branch lp:perl5

Related bugs

Related blueprints

Branch information

Registry Administrators

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://perl5.git.perl.org/perl.git.

The next import is scheduled to run in 3 hours.

Last successful import was 2 hours ago.

Import started 2 hours ago on pear and finished 2 hours ago taking 1 minute — see the log
Import started 8 hours ago on pear and finished 8 hours ago taking 50 seconds — see the log
Import started 14 hours ago on pear and finished 14 hours ago taking 1 minute — see the log
Import started 20 hours ago on neumayer and finished 20 hours ago taking 2 minutes — see the log
Import started on 2015-05-06 on neumayer and finished on 2015-05-06 taking 2 minutes — see the log
Import started on 2015-05-05 on pear and finished on 2015-05-05 taking 1 minute — see the log
Import started on 2015-05-05 on pear and finished on 2015-05-05 taking 1 minute — see the log
Import started on 2015-05-05 on pear and finished on 2015-05-05 taking 1 minute — see the log
Import started on 2015-05-05 on russkaya and finished on 2015-05-05 taking 1 minute — see the log
Import started on 2015-05-04 on neumayer and finished on 2015-05-04 taking 2 minutes — see the log

Recent revisions

49639. By Craig A. Berry <email address hidden> 4 hours ago

Fix unixify when beginning with current directory.

VMS::Filespec::unixify has been truncating its return value and
returning early when the input begins with [] meaning the current
directory. If there was nothing else, we've been getting the right

    [] --> ./

but if there was a file portion of the name it's been getting

    []foo.txt --> ./

which is now fixed. Looks like it's been broken since inception
in 5.002, though only with the specific [] case and not if there
was an explicit device or directory name.

49638. By Karl Williamson <email address hidden> on 2015-05-06

perlvar: Mention literal cntrls are deprecated in var names

49637. By Ricardo Signes <email address hidden> on 2015-05-06

Merge branch 'perldelta' into blead

49636. By David Mitchell <email address hidden> on 2015-05-05

fix weird comment in cop.h blurb

The original blurb which I added to the top of cop.h had an ambiguous
statement in it that sometime later got "corrected" into the wrong

49635. By David Mitchell <email address hidden> on 2015-05-05

null ptr deref in Perl_cv_forget_slab

RT #124385

Parsing following a syntax error could result in a null ptr dereference.

This commit contains a band-aid that returns from Perl_cv_forget_slab() if
the cv arg is null; but the real issue is much deeper and needs a more
general fix at some point.

Basically, both the lexer and the parser use the save stack, and after an
error, they can get out of sync.

In particular:

1) when handling a double-quoted string, the lexer does an ENTER, saves
most of its current state on the save stack, then uses the literal string
as the toke source. When it reaches the end of the string, it LEAVEs,
restores the lexer state and continues with the main source.

2) Whenever the parser starts a new block or sub scope, it remembers the
current save stack position, and at end of scope, pops the save stack back
to that position.

In something like

    "@{ sub {]}} }}}"

the lexer sees a double-quoted string, and saves the current lex state.
The parser sees the start of a sub, and saves PL_compcv etc. Then a parse
error occurs. The parser goes into error recovery, discarding tokens until
it can return to a sane state. The lexer runs out of tokens when toking
the string, does a LEAVE, and switches back to toking the main source.
This LEAVE restores both the lexer's and the parser's state; in particular
the parser gets its old PL_compcv restored, even though the parser hasn't
finished compiling the current sub. Later, series of '}' tokens coming
through allows the parser to finish the sub. Since PL_error_count > 0, it
discards the just-compiled sub and sets PL_compcv to null. Normally the
LEAVE_SCOPE done just after this would restore PL_compcv to its old value
(e.g. PL_main_cv) but the stack has already been popped, so PL_compcv gets
left null, and SEGVs occur.

The two main ways I can think of fixing this in the long term are
1) avoid the lexer using the save stack for long-term state storage;
in particular, make S_sublex_push() malloc a new parser object rather
than saving the current lexer state on the save stack.
2) At the end of a sublex, if PL_error_count > 0, don't try to restore
state and continue, instead just croak.

N.B. the test that this commit adds to lex.t doesn't actually trigger the
SEGV, since the bad code is wrapped in an eval which (for reasons I
haven't researched) avoids the SEGV.

49634. By Tony Cook <email address hidden> on 2015-05-05

[perl #124187] don't call pad_findlex() on a NULL CV

49633. By Karl Williamson <email address hidden> on 2015-05-05

perlunicode: Update nonchars discussion for Unicode 7.0

Unicode 7.0 changed the prohibition of noncharacters to merely "not
recommend" their use. Perl continues to forbid them in strict input
checking (otherwise security issues could arise), but the discussion
about them needs to be updated to correspond with their new status.

The message raised when they are used probaby should change
correspondingly, but it is too late for 5.22 for that.

This commit deletes some text elsewhere about the noncharacter code
points. This text really wasn't germane to a discussion about UTF-8
(wherein it appeared), as the encoding is irrelevant to these code
points. They're not recommended in any UTF format.

Unicode spells the term "noncharacter" without a hyphen. This pod
changes to follow that spelling.

49632. By Aristotle Pagaltzis on 2015-05-04

POSIX: Regeneralize export.t to non-ASCII platforms

This reverts commit 2da5b9bef2ef557a6978ec45042e29fa38e9bade and solves
the problem by sorting the expectation data instead, to make sure it is
consistent with the sort order of the comparison data. This removes the
need to depend on another file.

49631. By Karl Williamson <email address hidden> on 2015-04-30

PATCH: [perl #124348] re/pat_advanced solaris failure

Tony Cook traced this down to a compiler bug. But it's easy to change
the code to avoid the problem. The expression evaluates to 0; and was
only in the form that caused the failure to document what was going on.
Now, instead the failed form is shown in comments, and 0 is used

49630. By David Mitchell <email address hidden> on 2015-04-28

avoid uninit read in re_op_compile()

Some code in this function examines the first two nodes in the regex to
set suitable flags etc. Part of the code accesses the second node
by using regnext(first), other parts by NEXTOPER(first). The second method
only works when the node is the same size as a basic node. I *think*
that the code only makes use of this second value in situations where
the node *is* basic, but nevertheless, it makes valgrind unhappy when
the first node is an EXACT node, and reading the second node's
supposed type field is actually reading the padding bytes at the end of
the EXACT string, which are uninitialised.

So just use regnext() only.

Something as simple as /x/ on non-debugging builds was enough to make
valgrind complain. (On debugging builds, the program buffer is initially

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.


No subscribers.