Father Chrysostomos [Mon, 12 Aug 2013 07:28:31 +0000 (00:28 -0700)]
Alphabetise perldiag
Father Chrysostomos [Mon, 12 Aug 2013 07:28:07 +0000 (00:28 -0700)]
Increase $diagnostics::VERSION to 1.32
Father Chrysostomos [Mon, 12 Aug 2013 07:27:14 +0000 (00:27 -0700)]
diagnostics: don’t truncate wrapped links
Tony Cook [Mon, 12 Aug 2013 05:28:14 +0000 (15:28 +1000)]
[perl #117355] [lu]cfirst don't respect 'use bytes'
Tony Cook [Mon, 15 Jul 2013 06:16:22 +0000 (16:16 +1000)]
[perl #117355] unTODO the [lu]cfirst under bytes tests
Karl Williamson [Sun, 5 May 2013 02:42:48 +0000 (20:42 -0600)]
XXX Patch for discussion: [perl #117355] [lu]cfirst don't respect 'use bytes'
Tony Cook [Mon, 15 Jul 2013 06:06:46 +0000 (16:06 +1000)]
[perl #117355] very basic tests for [ul]c(first)? under use bytes
the [lu]cfirst tests are TODO due to #117355
Tony Cook [Mon, 12 Aug 2013 02:02:51 +0000 (12:02 +1000)]
[perl #3330] warn on increment of an non number/non-magically incable value
Tony Cook [Mon, 12 Aug 2013 03:21:18 +0000 (13:21 +1000)]
fix several problems in the MY_CXT example in perlxs.pod
- duplicate declaration of name for newMouse
- missing OUTPUT clauses
- use of a member of the context object that doesn't exist in
get_mouse_name()
- incorrect type assigned to RETVAL in get_mouse_name
- inconsistent indentation
- B<> to mark a heading instead of =headN
Craig A. Berry [Sun, 11 Aug 2013 20:04:52 +0000 (15:04 -0500)]
Forgot d_semctl in
a429ddf7a2c14d.
Ricardo Signes [Mon, 12 Aug 2013 00:33:08 +0000 (20:33 -0400)]
add Alexander Voronov to AUTHORS file
Alexander Voronov [Thu, 28 Feb 2013 12:25:55 +0000 (16:25 +0400)]
Update perlipc.pod
Ricardo Signes [Sun, 11 Aug 2013 23:22:20 +0000 (19:22 -0400)]
add Viktor Turskyi to the AUTHORS file
Viktor Turskyi [Sun, 19 May 2013 14:19:34 +0000 (17:19 +0300)]
Fixed typo (protoytpe => prototype)
Father Chrysostomos [Sun, 11 Aug 2013 20:45:06 +0000 (13:45 -0700)]
[Merge] Fixes to reset("...")
I tried to make copy-on-write more pervasive, and reset.t started
failing. So I found myself reworking sv_resetpvn (i.e., deleting
parts of it).
Father Chrysostomos [Sun, 11 Aug 2013 20:43:57 +0000 (13:43 -0700)]
Don’t taint undef in reset
reset was tainting undef if the internal SV type happened to be SVt_PV
or higher. This has got to have been a mistake. Tainting undef or
what is known to be an empty string does not make sense, even in a
tainted expression. Tainting it based on the internal type does not
make sense either, and results in inconsistencies in behaviour (taint
it if it *was* a string, even though it isn’t now, but not if it was a
number, unless that number was tied, or had pos() set, etc.).
This tainting has been here since perl 3.0 (commit
a687059cb), which I
think was when tainting was introduced.
Applying the tainting based on the internal type has happened since
79072805bf6 (perl 5.0 alpha 2), which introduced different internal
SV types.
Father Chrysostomos [Sun, 11 Aug 2013 20:14:03 +0000 (13:14 -0700)]
Remove special string handling from sv.c:sv_reset
Once upon a time, "" and undef were equivalent, and str_reset (as it
was called) would turn a scalar into an empty string.
Since commit
79072805bf6 (perl 5.0 alpha 2), sv_reset has set sca-
lars to undef.
Setting SvCUR to 0 and *SvPVX to '\0' (converted from str->cur and
str->ptr[0] by the same commit
79072805bf6) has not been neces-
sary since.
Father Chrysostomos [Sun, 11 Aug 2013 19:51:10 +0000 (12:51 -0700)]
sv.c:sv_reset: Remove %ENV handling; fix for VMS
The special env handling (calling my_clearenv) in sv_reset is com-
pletely unnecessary, because
• sv_reset calls hv_clear
• hv_clear calls mg_clear for magical arrays
• mg_clear calls magic_set_all_env for %ENV
• magic_set_all_env calls my_clearenv
so it gets called twice (confirmed with gdb breakpoints).
The VMS handling in sv_reset was wrong, because it was not even inside
the if(gv==PL_envgv) condition. It was croaking for any hash, not
just %ENV (the fault of commit
b0269e46d). (This was based on code
inspection; not actually tested.)
Handling %ENV specially in sv_reset has been unnecessary since ‘clear’
magic was added to %ENV in commit
fb73857aa (inseparable changes from
patch to perl 5.004_04).
Father Chrysostomos [Sun, 11 Aug 2013 19:29:31 +0000 (12:29 -0700)]
Stop reset from skipping @ % if $ is read-only
reset has been wrongly skipping arrays and hashes in the same glob as
read-only scalars since commit
9e35f4b3b4.
Father Chrysostomos [Sun, 11 Aug 2013 19:21:40 +0000 (12:21 -0700)]
reset.t: Basic tests for resetting aggregates
This probably incorrectly dies on VMS, based on code inspection. Com-
mit
b0269e46d appears to have added the VMS-specific code in the
wrong place.
Father Chrysostomos [Sun, 11 Aug 2013 18:52:35 +0000 (11:52 -0700)]
sv_reset: Don’t skip THINKFIRST items
Commit
9e35f4b3b4 made sv_reset skip SVs other than refs that had
SvTHINKFIRST set. Back then SvTHINKFIRST was only true for refe-
rences and read-only variables, so this change was technically cor-
rect (except for skipping arrays and hashes, which this commit
does not fix).
But SvTHINKFIRST was expanded later (beginning in commit
6fc926691,
by the author of
9e35f4b3b4), making this code in sv_reset wrong.
In all fairness, it was already wrong before for things marked FAKE,
just differently wrong.
Father Chrysostomos [Sun, 11 Aug 2013 19:05:49 +0000 (12:05 -0700)]
Fix threaded build broken by
823ac2c80
Father Chrysostomos [Sat, 10 Aug 2013 20:09:34 +0000 (13:09 -0700)]
Call get-magic before rejecting non-refs in sv_bless
Otherwise bless $tied_ref will die if FETCH hasn’t been called else-
where yet.
Father Chrysostomos [Sat, 10 Aug 2013 18:55:11 +0000 (11:55 -0700)]
gv.c:newGP: assert that PL_curcop is not NULL
It should never be null here, and we want to know if it is. (It can
be set to null in op.c:S_cop_free, but it should always have been set
to something else by the time newGP is called.)
Nevertheless, we should leave the null checks in place, to avoid sabo-
taging non-debugging builds if there are any remaining bugs here.
Father Chrysostomos [Sat, 10 Aug 2013 17:51:07 +0000 (10:51 -0700)]
gv.c:newGP: merge some threaded and non-threaded code
The previous commit cause the two alternate pieces of code to be
nearly identical.
Father Chrysostomos [Sat, 10 Aug 2013 17:46:43 +0000 (10:46 -0700)]
Restore NULL check to gv.c:newGP, removed by
19bad673
1df5f7c195 added checks to newGP to account for PL_curcop being NULL.
19bad673 inadvertently removed the NULL check for non-threaded builds,
except in one spot.
Since S_cop_free now sets PL_curcop to NULL as of the previous commit
(something
1df5f7c195 was meant to do but didn’t), this check is a
good idea, even though PL_curcop is never NULL here.
See also <
20130805200313.GS3729@plum.flirble.org>.
Father Chrysostomos [Sat, 10 Aug 2013 17:41:11 +0000 (10:41 -0700)]
Set PL_curcop to NULL in op.c:S_cop_free
Having PL_curcop pointing to a freed op is a Bad Idea and something
that has caused bugs in the past.
The intent of commit
1df5f7c195 was to do this, but this part of
the commit was accidentally omitted.
See <
20130805200313.GS3729@plum.flirble.org>.
Father Chrysostomos [Sat, 10 Aug 2013 17:38:08 +0000 (10:38 -0700)]
Make ++ handle regexps and vstrings
$ ./perl -Ilib -e 'use Devel::Peek; $x = v97; ++$x; Dump $x'
SV = PVMG(0x7fbfa402b698) at 0x7fbfa402eed8
REFCNT = 1
FLAGS = (RMG,POK,pPOK)
IV = 0
NV = 0
PV = 0x7fbfa3c066a8 "b"\0
CUR = 1
LEN = 24
MAGIC = 0x7fbfa3c06348
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_vstring(V)
MG_LEN = 3
MG_PTR = 0x7fbfa3c13ee8 "v97"
The vstring magic is still attached (with something that does not
match the contents of the string), even after modifying it. I
probably broke that in 5.18 after fixing it in 5.16, but I am too
lazy to check.
$ ./perl -le '$x = ${qr//}; $x++; print "$x"'
Assertion failed: (PL_valid_types_IVX[SvTYPE(_svivx) & SVt_MASK]), function Perl_sv_2pv_flags, file sv.c, line 2908.
Abort trap: 6
That I broke when I stopped regexps from being POK in perl 5.18.0.
It was creating a corrupt SV by setting the IOK flag on something of
type SVt_REGEXP.
Father Chrysostomos [Sat, 10 Aug 2013 17:01:06 +0000 (10:01 -0700)]
Stop -- from crashing on regexps
I mean dereferenced regexps, as returned by ${ qr// }.
It was creating a corrupt SV by setting the IOK flag on something
of type SVt_REGEXP.
This is something I broke when I stopped regexps from being POK
in perl 5.18.0.
Father Chrysostomos [Sun, 11 Aug 2013 15:08:08 +0000 (08:08 -0700)]
Make PL_hints an alias for PL_compiling.cop_hints
PL_hints stores the hints at compile time that get copied into the
cop_hints field of each COP (in newSTATEOP).
Since perl-5.8.0-8053-gd5ec298, COPs have stored all the hints.
Before that, COPs used to store only some of the hints. The hints
were copied here and there into PL_compiling, a static COP-shaped buf-
fer used during compilation, so that things like constant folding
would see the correct hints.
a0ed51b3 back in 1998 did that.
Now that COPs can store all the hints, we can just use
PL_compiling.cop_hints to avoid having to copy them from PL_hints from
time to time.
This simplifies the code and avoids creating bugs like those that
a547fd219 and
1c75beb82 fixed.
Father Chrysostomos [Sat, 10 Aug 2013 16:49:28 +0000 (09:49 -0700)]
Modifying ${^OPEN} changes the value of $^H:
$ ./perl -le 'BEGIN { print $^H; ${^OPEN} = "a\0b"; print $^H}'
256
917760
So changing $^H back should change the value of ${^OPEN} back to undef, right?
$ ./perl -le 'BEGIN { ${^OPEN} = "a\0b"; $^H=256; print ${^OPEN}//"undef"}'
ab
$ ./perl -le 'BEGIN { ${^OPEN} = "a\0b"; $^H=256;}BEGIN{ print ${^OPEN}//"undef"}'
undef
Apparently you have to hop from one BEGIN block to another to see
the changes.
This happens because compile-time hints are stored in PL_hints (which
$^H sets) but ${^OPEN} looks in PL_compiling.cop_hints. Setting
${^OPEN} sets both. The contents of PL_hints are assigned to
PL_compiling.cop_hints at certain points (the start of a BEGIN block
sees the right value because newSTATEOP sets it), but the two are not
always kept in synch.
The smallest fix here is to have $^H set PL_compiling.cop_hints as
well as PL_hints, but the ultimate fix--to come later--is to merge the
two and stop storing hints in two different places.
Father Chrysostomos [Sat, 10 Aug 2013 13:07:07 +0000 (06:07 -0700)]
sv.c: Remove more ro exceptions that c72a4ee missed.
Father Chrysostomos [Sat, 10 Aug 2013 12:30:41 +0000 (05:30 -0700)]
Fix booleanness of regexps
I broke this when I stopped regexps from being POK in 5.18.
Father Chrysostomos [Sat, 10 Aug 2013 11:48:17 +0000 (04:48 -0700)]
Make SvPVbyte work on tied non-PV
The magic check came too late. sv_utf8_downgrade does nothing if the
argument is not a PV.
So in the test added to svpv.t the returned string was in utf8,
not bytes.
Father Chrysostomos [Sun, 11 Aug 2013 14:51:25 +0000 (07:51 -0700)]
[Merge] Handle @INC filter return values better
Father Chrysostomos [Sat, 10 Aug 2013 01:14:31 +0000 (18:14 -0700)]
pp_ctl.c:S_run_user_filter: remove GMAGICAL check
We have already called get-magic at this point, so SvOK will give
the right answer even for magical variables. Concatenating it when
gmagical could give an uninitialised warning if it is undef, so
we don’t want to do that, as it would cause magical and non-mag-
ical undefs to behave differently. I don’t know how to write a
test for this.
Father Chrysostomos [Fri, 9 Aug 2013 20:32:30 +0000 (13:32 -0700)]
Handle magical return values from @INC filter
An @INC filter (a subroutined returned by a subroutine in @INC) could
be an lvalue sub that returns a magical scalar for the status. We
need to account for that.
If we don’t call get-magic (FETCH), we’ll get the last value assigned
to or returned from that scalar.
Father Chrysostomos [Fri, 9 Aug 2013 20:01:39 +0000 (13:01 -0700)]
Setting $_ to multiline glob in @INC filter
This commit corrects the one remaining code path in
pp_ctl.c:S_run_user_filter that was not handling non-PVs.
If we have to truncate $_ and keep the remainder in a cache (because
it has more than one line), we need to make sure we don’t assume it is
a PV when it comes to truncating it.
$ ./perl -Ilib -e '@INC = sub { sub { return 0 if $|--; $_ = *{"foo;\nbar"}; return 1 } }; do "foo"'
Assertion failed: (!isGV_with_GP(upstream)), function S_run_user_filter, file pp_ctl.c, line 5494.
Abort trap: 6
Father Chrysostomos [Fri, 9 Aug 2013 15:43:16 +0000 (08:43 -0700)]
incfilter.t: squelch warning
Father Chrysostomos [Fri, 9 Aug 2013 15:42:32 +0000 (08:42 -0700)]
Tying $_ in @INC filter
Crazy? Probably. But the existing code partially handles magic val-
ues already; it’s just buggy. Also, the magic value could come from
another source filter that is not registered via @INC, and this is one
way to test that code path.
Father Chrysostomos [Thu, 8 Aug 2013 19:49:57 +0000 (12:49 -0700)]
Handle non-PV $_ in @INC filters
@INC filters (code refs returned by code refs in @INC) are given the
current line of code in $_ and can modify it. The C code that invokes
the Perl filter is in pp_ctl.c:S_run_user_filter. It was not taking
into account that $_ might not have a PV pointer when it is returned,
and so this could result in crashes or assertion failures.
This commit forces the scalar to be a string before returning it to
the lexer, unless it is undef. If we force it to be a string when it
is undef, then existing tests start producing uninitialized warnings.
The logic is still faulty in places. Subsequent commits will
address that.
Father Chrysostomos [Wed, 7 Aug 2013 15:52:23 +0000 (08:52 -0700)]
op.c: Force shared hash key optimisation for existing COWs
If COW scalars are becoming more prevalent (they are), the hash key
optimisation will be less and less likely to kick in if it is skipped
for anything already SvIsCOW.
The assumption is that such a scalar is already a shared hash key sca-
lar. That is not true for copy-on-write scalars made such by the new
mechanism that allows existing non-COW scalar to be upgraded to such.
The purpose of using shared hash keys scalars here is that the precom-
puted hash is already stored in the scalar (ok, it points to it indi-
rectly), speeding up hash lookup.
New COW scalars don’t have that and offer no speedup here.
So skip the optimisation only when the COW scalar is a shared hash
key scalar.
All of the above applies to methods as well.
Father Chrysostomos [Sun, 11 Aug 2013 14:41:45 +0000 (07:41 -0700)]
[Merge] Read-only COWs
Commit
9a0a85075 made shared hash key constants read-only. This meant
that copy-on-write scalars (shared hash key scalars are one type
of this) could have the read-only flag set, which could not hap-
pen before.
Much code still assumed that read-only && !cow was the proper way to
check for read-onliness (which was correct before perl 5.18, when
READONLY+FAKE meant COW).
This branch fixes up all the instances if SvIsCOW to work correctly
with read-only COWs.
It also allows Internals::SvREADONLY to make a COW read-only without
stopping it from being a COW (affecting constant.pm and Hash::Util).
I also went and fixed up tests under -DPERL_OLD_COPY_ON_WRITE and
-DPERL_NO_COW, in the process of making sure I wasn’t breaking those.
Father Chrysostomos [Sat, 10 Aug 2013 20:06:26 +0000 (13:06 -0700)]
Don’t allow read-only COWs to be blessed
The logic exempting copy-on-write scalars from read-only checks in
sv_bless was left over from when READONLY+FAKE meant copy-on-write.
Father Chrysostomos [Sat, 10 Aug 2013 13:06:56 +0000 (06:06 -0700)]
In sv.c:sv_magic don’t allow tying ro COWs
Read-only COWs are read-only and should not be treated as though they
were not. This logic is left over from when READONLY+FAKE meant
copy-on-write.
Father Chrysostomos [Sat, 10 Aug 2013 03:22:29 +0000 (20:22 -0700)]
Stop system select from croaking on read-only COW ""
System select (select with 4 arguments) does not allow any of its
first three arguments to be read-only unless they are undef or
empty strings.
It does not work properly for read-only copy-on-write empty strings,
because it passes all copy-on-write through sv_force_normal under the
expectation that they will shortly be modified. It should not be
doing that for read-only empty strings.
Father Chrysostomos [Sat, 10 Aug 2013 01:36:39 +0000 (18:36 -0700)]
Read-only COWs should not be exempt from s/// croaking
$ ./miniperl -Ilib -e 'for(__PACKAGE__) { s/a/a/ }'
Modification of a read-only value attempted at -e line 1.
$ ./miniperl -Ilib -e 'for(__PACKAGE__) { s/b/b/ }'
$ ./miniperl -Ilib -e 'for("main") { s/a/a/ }'
Modification of a read-only value attempted at -e line 1.
$ ./miniperl -Ilib -e 'for("main") { s/b/b/ }'
Modification of a read-only value attempted at -e line 1.
When I pass the constant "main" to s///, it croaks whether the regular
expression matches or not.
When I pass __PACKAGE__, which has the same content and is also read-
only, it only croaks when the pattern matches.
This commit removes some logic that is left over from when
READONLY+FAKE meant copy-on-write. Read-only does mean read-only now,
so copy-on-write scalars should not be exempt from read-only checks.
Father Chrysostomos [Wed, 7 Aug 2013 15:12:27 +0000 (08:12 -0700)]
Remove SvIsCOW checks from mg.c:mg_localize
It no longer needs to worry about SvIsCOW. This logic is left over
from when READONLY+FAKE was used for COWs.
Since it is possible for COWs to be read-only now, this logic is actu-
ally faulty, as it doesn’t temporarily stop read-only COWs from being
read-only, as it does for other read-only values.
This actually causes discrepancies with scalar-tied locked hash keys,
which differ in readonliness when localised depending on whether the previous value used copy-on-write.
Whether such scalars should be read-only after localisation is open
to debate, but it should not differ based on the means of storing the
previous value.
Father Chrysostomos [Wed, 7 Aug 2013 07:56:32 +0000 (00:56 -0700)]
Remove SvIsCOW checks from mg.c:S_save_magic
It no longer needs to worry about SvIsCOW. This logic is left over
from when READONLY+FAKE was used for COWs.
Since it is possible for COWs to be read-only now, this logic is actu-
ally faulty, as it doesn’t temporarily stop read-only COWs from being
read-only, as it does for other read-only values.
This actually causes bugs with scalar-tied locked hash keys, which
croak on FETCH.
Father Chrysostomos [Wed, 7 Aug 2013 01:19:08 +0000 (18:19 -0700)]
Don’t treat COWs specially in locked hashes
This is left over from when READONLY+FAKE meant copy-on-write.
Read-only copy-on-write scalars (which could not occur with the old
way of flagging things) must not be exempt from hash key restrictions.
Father Chrysostomos [Tue, 6 Aug 2013 20:05:20 +0000 (13:05 -0700)]
Make tr/a/b/ croak on read-only null COWs
$ ./perl -Ilib -e 'use constant nullrocow => (keys%{{""=>undef}})[0]; for(nullrocow) { y/a/b/ }'
$ ./perl -Ilib -e 'use constant nullro => ""; for(nullro) { y/a/b/ }'
Modification of a read-only value attempted at -e line 1.
It should croak on COW scalars that are read-only, even if they are
zero-length, just as it does on non-COW scalars.
This logic is left over from when READONLY+FAKE meant COW.
Father Chrysostomos [Sun, 11 Aug 2013 01:19:55 +0000 (18:19 -0700)]
Fix up Peek.t for alternate COW configurations
I.e., -DPERL_OLD_COPY_ON_WRITE and -DPERL_NO_COW
Father Chrysostomos [Sun, 11 Aug 2013 06:30:33 +0000 (23:30 -0700)]
Make OLD_COPY_ON_WRITE handle SvLEN==0 scalars
SvLEN==0 means the scalar does not own the buffer.
PERL_OLD_COPY_ON_WRITE can’t do its copy-on-write with those, as
SvIsCOW && SvLEN==0 means a shared hash key scalar.
PerlIO::encoding passes such scalars to the Encode object’s
encode method.
Why am I even fixing this? I was trying to make sure that I wasn’t
breaking PERL_OLD_COPY_ON_WRITE with other changes. I got assertion
failures from encoding.t so I looked to see what the problem might be,
thinking it could affect other configurations. It turns out not to be
specific to PERL_OLD_COPY_ON_WRITE, but since I have found the problem
I might as well fix it anyway.
Father Chrysostomos [Tue, 6 Aug 2013 13:25:59 +0000 (06:25 -0700)]
universal.c: Ignore SvIsCOW in XS_Internals_SvREADONLY
SvIsCOW used to check SVf_READONLY|SVf_FAKE.
e3918bb703ca changed
that, but did not change the assumptions that code already made (that
there could be not truly read-only COWs.
Now SvREADONLY actually means read-only, so Internals::SvREADONLY
should not be saying that read-ony COWs are not, nor does it need to
flatten COWs when making them read-only. Hence, locking hash values
no longer has a speed and memory hit if that hash contains COWs.
Part of the code is left in place for PERL_OLD_COPY_ON_WRITE, to avoid
making read-only COWs under that configuration. See the previous com-
mit for why.
Father Chrysostomos [Sat, 10 Aug 2013 23:28:40 +0000 (16:28 -0700)]
op.c:ck_svconst: Don’t allow ro COWs under old COW
Under PERL_OLD_COPY_ON_WRITE, allowing COWs to become read-only will
complicate things elsewhere. It uses the IV slot of an SV to point
to a loop of SVs sharing the same buffer. sv_2iv cannot cache the IV
without running the SV through sv_force_normal, but that will croak on
read-only values. I could change it to S_sv_uncow, but there are more
cases elsewhere that would have to be audited, I don’t think it’s
worth spending time on improving PERL_OLD_COPY_ON_WRITE as it’s ‘dead
code, never intended to go live’ according to its author. I am
bothering with at least this much because I don’t want to break it
knowingly.
Nicholas Clark [Wed, 7 Aug 2013 10:23:57 +0000 (12:23 +0200)]
test.pl's runperl() can now optionally redirect STDIN from /dev/null
There is existing code to pipe fixed input to the test perl's STDIN, which
means that STDIN can be made to be an immediate end-of-file by giving an
empty string. However, it turns out that on platforms which use ksh as
/bin/sh, ksh's setup of shell pipelines differs from a traditional Bourne
shell (and bash), using one less process in total, with the result that the
test perl starts with a child process already - the process piping to its
STDIN. This unexpected child process confuses tests for wait() which are
only expecting to see return values from processes that the test script
itself started.
As the problem case is specifically for setting up STDIN to be at EOF, it's
easier to it by enhancing test.pl's runperl() to be able to redirect STDIN
from the null device than by making the tests themselves more complex.
This approach also avoids spawning a process for quite a few of the tests.
Fortuitously it seems that the string /dev/null is portable enough to work
with the command line parsing code on VMS and Win32 too.
Thanks to Zefram for helping diagnose the problem.
It turns out that this also fixes regressions on VMS, where the pipe
implementation returns the exit code of the process at the front of the
pipeline, not the end. The result is that adding a pipeline messes up any
test using OPTION FATAL to check exit status.
Nicholas Clark [Wed, 7 Aug 2013 09:57:09 +0000 (11:57 +0200)]
Remove the two "VMS adjustments" from test.pl's _fresh_perl
These were added by commit
ed6b3797850720f7 ("make t/op/misc.t work on VMS")
in Jan 2001 back when the relevant code was in t/op/misc.t
The two adjustments each only applied to one test in t/run/fresh_perl.t
Was: system './perl -ne "print if eof" /dev/null'
Became: system './perl -ne "print if eof" NL:'
Was: print "ok\n" if (-e _ and -f _ and -r _);
Became: print "ok\n" if (-e _ and -f _);
The latter had the comment "VMS file locking".
It seems that neither is needed now. Perl will recognise "/dev/null" as
the null device, and -r returns true on a file opened for reading.
The "adjustments", particularly the second, should have been done all along
in the code for the test itself, not by complicating the test runner.
Craig A. Berry [Sun, 11 Aug 2013 13:45:49 +0000 (08:45 -0500)]
Probe for shm* routines in configure.com.
They became available in ACRTL ECO V0100 on VMS v8.4, but aren't
quite ready for prime time yet. Specifically, shmget fails
unless IPC_CREAT is set in the third argument, but Perl has tests
that explicitly check that this is not necessary.
So construct the probe such that we won't enable these routines
until the CRTL bug has been fixed.
Karl Williamson [Sun, 11 Aug 2013 04:12:28 +0000 (22:12 -0600)]
t/re/re_tests: Move vim hints to eof
Commit
c30fc27b appended lines in the file to after the editor hints
lines. This caused my vim to not notice them.
Karl Williamson [Fri, 2 Aug 2013 20:13:16 +0000 (14:13 -0600)]
regcomp.h, sv.c, utf8.c: Comment nits
Remove obsolete comment, typos in others, plus reflow one block to fit
into 79 columns
Lukas Mai [Sat, 10 Aug 2013 22:44:09 +0000 (00:44 +0200)]
add adjust_size_and_find_bucket to embed.fnc
Shlomi Fish [Sat, 10 Aug 2013 07:24:00 +0000 (10:24 +0300)]
Remove some effect-less code.
Discussed in RT #41461
Shlomi Fish [Sat, 10 Aug 2013 07:21:16 +0000 (10:21 +0300)]
Fix RT #41461 (with a test).
A problem with the perl debugger of writing to an undef $LINEINFO.
Bump $VERSION to 1.42.
For: RT #41461
Craig A. Berry [Sat, 10 Aug 2013 13:07:18 +0000 (08:07 -0500)]
Add two "ld" variables missing from configure.com.
This should close [perl #119197].
Sergey Alekseev [Fri, 9 Aug 2013 13:55:59 +0000 (19:55 +0600)]
Function name typo in malloc.c
Error was also spotted by mauke.
For: RT #119213
Father Chrysostomos [Fri, 9 Aug 2013 21:24:23 +0000 (14:24 -0700)]
Make constant folding use the right hints
This was brought up in ticket #117855.
PL_compiling is a cop-sized static buffer (inside the interpreter
struct under threads) that stores information during compile time
(such as file name and line number) that gets copied to each cop (con-
trol op; aka state op or nextstate op) as it is created.
Some values are not actually stored in PL_compiling, such as the
current stash (PL_curstash is used instead) and the current hints
(PL_hints is used).
The ops in each statement are created before that statement’s cop
is created.
At run time, each cop is executed at the start of the statement and
sets PL_curcop to point to itself, so that operators within that
statement can get information from PL_curcop.
Constant folding was copying the contents of PL_compiling into a tem-
porary cop used to execute the ops being folded. That constant fold-
ing happened of course before the cop was created for that statement.
Now it just happened that commit
a0ed51b321 back in 1998 modified
newSTATEOP to copy hints to PL_compiling in addition to the new cop
being created. Presumably that was to fix the type of bug that this
commit is addressing. (Presumably this commit renders those changes
unnecessary.) That meant that most of the time constant folding would
see the right hints.
That fails, though, when it comes to the first statement in a string
eval. When you do eval("uc(ä)"), the constant folding happens when
PL_compiling.cop_hints still points to whatever value it had before
the eval was executed; i.e., an unpredictable value. Slight changes
to unrelated scopes (and, apparently, using a different compiler*) can
cause the result of that string eval to change.
The solution is to set the hints from PL_hints explicitly when doing
constant folding.
* <https://rt.perl.org/rt3/Ticket/Display.html?id=117855#txn-1241613>ff.
I never got to the bottom of why the compiler would make a diffe-
rence here. Finding out would involve setting a watchpoint on
PL_compiling.cop_hints in a C debugger and then stepping through
the thousands of times PL_compiling changes, which is too much
work. Nevertheless, I know this fix is correct, as it changes
PL_compiling.cop_hints from having a non-deterministic value during
constant folding to having a predictable one.
Father Chrysostomos [Sat, 10 Aug 2013 01:00:22 +0000 (18:00 -0700)]
toke.c:S_incline: avoid vivifying GV under threads
Since
c82ecf346 has been reverted by the previous commit, under
threads we are back to storing the name of the current file in the
cop, rather than a pointer to the GV. This means the GV may not even
have been created, so CopFILEGV will autovivify it. We can avoid
autovivifying it in those cases where we are not going to be copying
the lines anyway, which S_incline only does for string eval (when it
sees a #line directive). Even if the GV already exists, this makes
the check faster, as we no longer have to look it up by name when
parsing a file.
Father Chrysostomos [Sat, 6 Jul 2013 05:51:50 +0000 (22:51 -0700)]
Revert "[perl #117855] Store CopFILEGV in a pad under ithreads"
This reverts commit
c82ecf346.
It turn out to be faulty, because a location shared betweens threads
(the cop) was holding a reference count on a pad entry in a particu-
lar thread. So when you free the cop, how do you know where to do
SvREFCNT_dec?
In reverting
c82ecf346, this commit still preserves the bug fix from
1311cfc0a7b, but shifts it around.
Father Chrysostomos [Fri, 9 Aug 2013 21:44:35 +0000 (14:44 -0700)]
Revert "toke.c:incline: Avoid duplicate symbol lookup"
This reverts commit
05c9917c892c03577828027ff71c6282a2eabe29.
This is in preparation for reverting
c82ecf346, which will remove the
CopFILEGV_set macro under threads.
Father Chrysostomos [Fri, 9 Aug 2013 19:56:03 +0000 (12:56 -0700)]
dump.c: Dump contents of regexps’ mother_re field
This can make debugging easier if one needs to see the reference count
of the parent regular expression.
Father Chrysostomos [Thu, 8 Aug 2013 21:17:08 +0000 (14:17 -0700)]
op.c:ck_eval: remove redundant null check
op_first is never null when OPf_KIDS is set.
Father Chrysostomos [Thu, 8 Aug 2013 01:21:00 +0000 (18:21 -0700)]
Avoid assert fail with s// $target = \3 /e
When the substitution target is assigned to in pp_substcont, it is
assumed that SvPV_free and SvPOK_only_UTF8 can be used on that target.
Only COW scalars are sent through sv_force_normal.
Changing the target in the replacement code can render those assump-
tions untrue:
$ ./perl -Ilib -e '$h = 3; $h =~ s/3/$h=\3;4/e'
Assertion failed: (!((targ)->sv_flags & 0x00000800) || !(*({ SV *const _svrv = ((SV *)({ void *_p = (targ); _p; })); (__builtin_expect(!(PL_valid_types_RV[((svtype)((_svrv)->sv_flags & 0xff)) & 0xf]), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "PL_valid_types_RV[SvTYPE(_svrv) & SVt_MASK]") : (void)0); (__builtin_expect(!(!((((_svrv)->sv_flags & (0x00004000|0x00008000)) == 0x00008000) && (((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVGV || ((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVLV))), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "!isGV_with_GP(_svrv)") : (void)0); (__builtin_expect(!(!(((svtype)((_svrv)->sv_flags & 0xff)) == SVt_PVIO && !(((XPVIO*) (_svrv)->sv_any)->xio_flags & 64))), 0) ? __assert_rtn(__func__, "pp_ctl.c", 269, "!(SvTYPE(_svrv) == SVt_PVIO && !(IoFLAGS(_svrv) & IOf_FAKE_DIRP))") : (void)0); &((_svrv)->sv_u.svu_rv); }))), function Perl_pp_substcont, file pp_ctl.c, line 269.
Abort trap: 6
Also, matching against a hash key and locking that key with Hash::Util
within the replacement code can cause the substitution to modify that
hash key without triggering ‘Modification of a read-only value’. But
this only happens if it is not a copy-on-write scalar:
$ ./perl -Ilib -MHash::Util=lock_hash -le '$h{foo} = 3; $h{foo} =~ s/3/$h{foo} = 3; lock_hash %h; 4/e; print $h{foo}'
4
We need to do a regular SV_THINKFIRST_COW_DROP check here, just as we
do in sv_setsv with regular scalar assignment.
Also, we need to take into account real globs:
$ ./perl -Ilib -MHash::Util=lock_hash -le '$::{foo} =~ s//*{"foo"}; 4/e'
Assertion failed: (!isGV_with_GP(targ)), function Perl_pp_substcont, file pp_ctl.c, line 259.
Abort trap: 6
Father Chrysostomos [Wed, 7 Aug 2013 16:04:20 +0000 (09:04 -0700)]
Respect SvLEN==0 and SvOOK in sv.c:sv_sethek
SvLEN==0 means this scalar does not own the buffer, so it should
not free it.
SvOOK means that SvPVX does not point to the start of the buffer
because we have cheated with s/...// or substr and not copied the
string back.
I don’t believe any such scalars currently make their way into
sv_sethek and get past the THINKFIRST check in that state, but we
should still play it safe.
SvPV_free handles both cases.
Father Chrysostomos [Wed, 7 Aug 2013 15:46:52 +0000 (08:46 -0700)]
Don’t stringify undef hash keys at compile time
$ ./perl -wIlib -Mconstant' u=>undef' -e '()=$a{+u} if $a'
Use of uninitialized value at -e line 1.
Well, I didn’t even execute that hash lookup, so why is it warning me
about an uninitialized value?
This is a compile-time optimisation to turn hash keys into shared hash
key scalars (containing precomputed hashes) to speed up key lookup.
It stringifies the hash key at compile time as part of the process.
The value should not be stringified if that would cause observable
difference with tied hashes. Commit
04698ff67 fixed this for refs,
globs and regexps, but missed undef scalars.
This could be considered part of bug #79178.
Steffen Mueller [Fri, 9 Aug 2013 17:07:27 +0000 (19:07 +0200)]
ExtUtils::ParseXS: Version consistency
Steve Hay [Fri, 9 Aug 2013 12:00:37 +0000 (13:00 +0100)]
Update versions and dates in release announcement template
Tony Cook [Fri, 9 Aug 2013 06:46:00 +0000 (16:46 +1000)]
Darin McBride [Fri, 9 Aug 2013 06:17:08 +0000 (16:17 +1000)]
Carp now handles objects with string overloads.
It also allows objects to specify how they appear in the stack dump with
a CARP_TRACE method, and also allows the user to specify their own
formatter for objects without CARP_TRACE as well as other references.
[perl #92446]
Minor fix, commit message reformatting and manifest update by Tony Cook.
Tony Cook [Fri, 9 Aug 2013 02:10:06 +0000 (12:10 +1000)]
Tony Cook [Fri, 9 Aug 2013 01:41:26 +0000 (11:41 +1000)]
[perl #117793] remove dangerous functions and improve SvREFCNT()
This allows Devel::Peek::SvREFCNT() to work on any variable, not just
scalars, but has a chance of breaking backward compatibility.
Also changes the type of SvREFCNT() to U32 to match the type returned by
the underlying macro
Steve Hay [Thu, 8 Aug 2013 20:21:42 +0000 (21:21 +0100)]
Upgrade libnet from 1.22 to 1.22_02
This is the latest (development) release on CPAN. It will shortly be
superseded by 1.23.
Note that Makefile.PL is only customized -- not excluded as well! Two
customized test files (actually, one changed and one added) which blead
had (but were not noted in the Maintainers.pl file!) are incorporated in
this release.
Also, change the UPSTREAM status from undef to 'blead' to reflect the fact
that GBARR is no longer actively maintaining libnet and for the immediate
future new CPAN releases are only likely to be rolled to keep in sync with
changes in blead, plus occasional simple patches from the CPAN RT queue.
James E Keenan [Tue, 6 Aug 2013 01:12:55 +0000 (21:12 -0400)]
Document non-destructive substitution: the '/r' modifier.
Per bug report filed by Jacinta Richardson++.
For: RT #119151
Chris 'BinGOs' Williams [Wed, 7 Aug 2013 22:48:21 +0000 (23:48 +0100)]
Add missing versioned Config to Module::CoreList
Chris 'BinGOs' Williams [Wed, 7 Aug 2013 22:34:14 +0000 (23:34 +0100)]
Config has a VERSION, corelist.pl should set it
Nicholas Clark [Wed, 7 Aug 2013 16:58:00 +0000 (18:58 +0200)]
Update the Porting/bisect.pl documentation.
As of commit
c8fde7fafa0a9cec (merged to blead with commit
4724da031eae31b4)
bisect.pl can be run in-place if the checkout is clean.
The most recent stable release that it will try is now v5.18.0.
Nicholas Clark [Wed, 7 Aug 2013 12:46:05 +0000 (14:46 +0200)]
Report the perl executable path in the error if Config.pm is out of sync.
If the version that Config.pm was built for differs from the version of the
perl executable running it, Config.pm aborts with an error message. The
error message was updated to include $0 (the script filename) in Aug 2010 by
commit
b982c5de5a0d9f6f. Somewhat misleadingly the commit message says
"include the path of the perl executable in the error message." which $0 is
not.
This commit adds $^X to the error message - the path of the perl executable.
The error message also shows the script name, as this might also be useful
in diagnosing the cause of the problem.
Nicholas Clark [Wed, 7 Aug 2013 12:29:50 +0000 (14:29 +0200)]
A comment in Storable.xs was words missing two words.
Steve Hay [Wed, 7 Aug 2013 11:39:59 +0000 (12:39 +0100)]
Upgrade IPC::Cmd from 0.82 to 0.84
James E Keenan [Sun, 4 Aug 2013 02:30:42 +0000 (22:30 -0400)]
Clarify documentation re switch expecting an argument but none is provided.
When a switch is expecting an argument but fails to be provided with one, the
value of the corresponding element in the options hash is set to the undefined
value. The documentation did not make this clear.
The documentation for getopts() and getopt() has been revised and additional
tests have been provided to demonstrate the point. Tweaked in response to
feedback from Karl Williamson++.
Also, unit tests found in lib/Getopt/Std.t actually for Getopt::Long have been
removed. A patch holding those tests has been submitted to Getopt-Long's bug
queue on rt.cpan.org.
For: RT #41359
Nicholas Clark [Wed, 7 Aug 2013 09:30:05 +0000 (11:30 +0200)]
Merge the refactoring of B which silences Solaris compiler warnings.
Nicholas Clark [Tue, 6 Aug 2013 12:07:42 +0000 (14:07 +0200)]
In B::OP::next, flag special cases with a type, instead of an offset of -1.
This permits the offset structure member to be unsigned instead of signed,
which feels more natural. The refactoring also reduces code size by about
100 bytes on x86_64.
Nicholas Clark [Tue, 6 Aug 2013 11:55:27 +0000 (13:55 +0200)]
Re-indent a switch statement in B::OP::next
This is the whitespace-only part of the next commit separated out.
Nicholas Clark [Tue, 6 Aug 2013 11:15:13 +0000 (13:15 +0200)]
Change all B's unsigned constants from IVs to UVs.
Apart from HEf_SVKEY, all constants are actually unsigned, so this change
avoids 2 warnings "initializer does not fit or is out of range" from the
Solaris C compiler for the two constants with the value 0x80000000
Nicholas Clark [Tue, 6 Aug 2013 10:56:04 +0000 (12:56 +0200)]
In B.xs use I16 to avoid an "initializer will be sign-extended" warning.
The Solaris C compiler warns 30 times that -1 will be sign-extended, when
it is assigned to a struct member of type size_t. Instead, use I16 (No offset
will actually be larger than 1024), and reduce the size of the types used for
other structure members.
Change SVp (etc) to be constants in the range 0x0 to 0x7, instead of 0x00000
to 0x70000, now that most use cases no longer involve to or-ing with other
values. This makes two switch statements simpler.
As well as quietening warnings, the combined changes reduce the object size
by about 800 bytes on x86_64.
Nicholas Clark [Tue, 6 Aug 2013 16:22:42 +0000 (18:22 +0200)]
Teach makedef.pl that Perl_allocfilegv does not exist without ithreads.
This linker skip was missed by commit
c82ecf346a8512f2, which did add the 3
PL_ variables it added for ithreads builds.
Craig A. Berry [Wed, 7 Aug 2013 02:09:40 +0000 (21:09 -0500)]
Don't multiply define Perl__invlist_dump.
It doesn't need to be in the extension if it's already in the core
top-level code. Defining it more than once leads to linker errors
for linkers that care about such things, namely VMS.
Broken in
ad3f05adb1975.
Steve Hay [Tue, 6 Aug 2013 21:47:50 +0000 (22:47 +0100)]
Fix t/porting/customized.t --regen not to add DOS EOLs on Windows
David Mitchell [Tue, 6 Aug 2013 15:34:50 +0000 (16:34 +0100)]
reparse compile-time /(?{})/ in right scope
When a compile-time regex like /...(?{ code-block }) .../
is compiled in the presence of constant and concat overloading,
this can cause (still at compile-time) for the pattern to be evaled and
re-compiled, in order to re-compile any code-blocks that got messed up
during the overloading and thus whose text no longer matches that which
the perl parser previously compiled.
When this happens, eval_sv() happens to be called when the perl parser is
still in compiling state; normally its called from running state.
This tickles an undiscovered bug in Perl_find_runcv_where(), which
finds the current cop sequence by looking at PL_curcop->cop_seq.
At compile time, we need to get it from PL_cop_seqmax instead.
Father Chrysostomos [Tue, 6 Aug 2013 13:08:21 +0000 (06:08 -0700)]
[perl #119169] index with __PACKAGE__ for 2nd argument
The refactoring of fbm_compile in
66379c06cd to prepare for
c72a4eedff1 put in an SvIsCOW check before doing SvPV_force. I sim-
ply changed the logic there so that SvPV_force would continue to have
its effect but without tripping up on read-only variables for which
SvPV_force would not need to make any changes anyway.
Now, if a COW scalar is read-only, we can’t call SvPV_force on it,
because it will die.
It turns out that we don’t actually need to call SvPV_force on COWs.
We can just go ahead and attach the BM magic and continue sharing
the buffer.
Father Chrysostomos [Tue, 6 Aug 2013 12:57:26 +0000 (05:57 -0700)]
sv.h: Add comment about gv_check and SvIsCOW
So that future refactorings don’t make use of 0x00010000 on
hashes without modifying gv_check to account.