| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Also fix one skip that should have been for B, not PerlIO.
|
| |
|
|
| |
fixes #17971
|
| | |
|
| |
|
|
| |
Prevents treating a large file position as negative (or even wrapped).
|
| | |
|
| |
|
|
|
| |
previosly seek() would produce an error, but would still make the\
file position negative.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ ./perl t/TEST ../cpan/Test-Simple/t/subtest/bail_out.t
t/../cpan/Test-Simple/t/subtest/bail_out ... Use of uninitialized value in open at /Users/sprout/Perl/perl.git-copy/cpan/Test-Simple/../../lib/Test/Builder.pm line 1895.
ok
All tests successful.
u=0.01 s=0.00 cu=0.09 cs=0.01 scripts=1 tests=2
Notice the uninitialized value.
$ ./perl -Ilib -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'
Use of uninitialized value $x in open at -e line 1.
$ perl5.18.1 -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'
I caused that in v5.19.5-44-g5a2bc23:
$ ../perl.git/Porting/bisect.pl --start=045071eede --end=blead -e 'use warnings FATAL=>"uninitialized"; open $fh, ">>", \$x'
...
5a2bc23bfe5dc60ff957cb44ffaa57668d56d238 is the first bad commit
commit 5a2bc23bfe5dc60ff957cb44ffaa57668d56d238
Author: Father Chrysostomos <sprout@cpan.org>
Date: Fri Oct 25 06:15:30 2013 -0700
Better fix for #119529
|
| |
|
|
|
|
|
| |
Just spotted this....
If the target scalar contains something already, then setting SvCUR to
0 is not sufficient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<$fh> used to loop if $fh was opened to an in-memory handle containing
a reference.
Commit 552908b174 fixed the loop by forcing a reference to a string
when the handle was created. It did not take into account that the
reference might be read-only. It was also insufficient, in that
the target scalar could be set to a reference after the handle
was created.
The real reason it was looping was that the code for returning and
setting the size of the buffer was not handling non-PVs properly
(unless they were globs, which were special-cased). It might return
0, and it might not, depending on what the internal SV field hap-
pened to hold.
This caused looping under 5.12 and onwards, but even in 5.10 <$fh>
returned nothing.
In this case, deleting code makes things just work.
Reverting the hunk from 552908b174 stops appending to refs from work-
ing, so I tweaked PerlIOScalar_pushed to fix that (which also reduced
the amount of code).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If $s in
open my $fh, "<", \$s
or similar is a ref, then
stringify that ref: i.e. convert it from a ref into the string
"SCALAR(0x....)" or whatever.
This fixes
RT #119529 Filehandle opened from ref to ref hangs on reading
which in this case was looping forever, since it kept thinking that
the var was a string ("SCALAR.."), but whose length was 0.
I haven't gone for a complete "always force var into a string" approach,
since PerlIO::scalar has quite a tolerance for "bad" vars; e.g.
it won't warn if $var is undef or a read-only constant number etc;
and it already normalises under some circumstances and not others.
So I've just increased the cases somewhat where it normalises.
Also, I didn't look to closely at the code that was looping (or to put it
another way, I looked at it but didn't understand it), so it could
conceivably still behave badly on some other strange type of variable that
manages to avoid getting normalised.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
if the scalar can be downgradable, it is downgraded and the read succeeds.
Otherwise the read fails, producing a warning if enabled and setting
errno/$! to EINVAL.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In trying to fix bug #112780, I made in-memory handle duplication tem-
porarily hide the underlying scalar so it wouldn’t be set to the empty
string (commit 49b69fb3a).
I used PerlIO_sv_dup in j rather than PerlIOScalar_arg. The for-
mer is usually what is called anyway. There is only one branch of
PerlIOScalar_arg that doesn’t call PerlIO_sv_dup. I don’t remember
what I was thinking back then, but I think I thought that branch
was there for paranoia. But actually, it is used for "&=", so this
started failing:
open FILE, '>', \my $content or die "Couldn't open scalar filehandle";
open my $fh, ">&=FILE" or die "Couldn't open: $!";
print $fh "Foo-Bar\n";
close $fh;
close FILE;
print $content;
This commit fixes the bug in the smallest way possible, which means
switching from PerlIO_sv_dup to PerlIOScalar_arg in PerlIOScalar_arg,
which, in turn, entails fiddling with RVs.
|
| |
|
|
|
| |
Lesson learnt: After switching from threaded to unthreaded and fixing
the test, switch back again and re-run the test. :-)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PerlIO::scalar’s dup function (PerlIOScalar_dup) calls the base imple-
mentation (PerlIOBase_dup), which pushes the scalar layer on to the
new file handle.
When the scalar layer is pushed, if the mode is ">" then
PerlIOScalar_pushed sets the scalar to the empty string. If it is
already a string, it does this simply by setting SvCUR to 0, without
touching the string buffer.
The upshot of this is that newly-cloned in-memory handles turn into
the empty string, as in this example:
use threads;
my $str = '';
open my $fh, ">", \$str;
$str = 'a';
async {
warn $str; # something's wrong
}->join;
This has probably always been this way.
The test suite for MSCHWERN/Test-Simple-1.005000_005.tar.gz does some-
thing similar to this:
use threads;
my $str = '';
open my $fh, ">", \$str;
print $fh "a";
async {
print $fh "b";
warn $str; # "ab" expected, but 5.15.7-9 gives "\0b"
}->join;
What was happening before commit b6597275 was that two bugs were can-
celling each other out: $str would be "" when the new thread started,
but with a string buffer containing "a" beyond the end of the string
and $fh remembering 1 as its position. The bug fixed by b6597275 was
that writing past the end of a string through a filehandle was leaving
junk (whatever was in memory already) in the intervening space between
the old end of string and the beginning of what was being written to
the string. This allowed "" to turn magically into "ab" when "b" was
written one character past the end of the string. Commit b6597275
started zeroing out the intervening space in that case, causing the
cloning bug to rear its head.
This commit solves the problem by hiding the scalar temporarily
in PerlIOScalar_dup so that PerlIOScalar_pushed won’t be able to
modify it.
Should PerlIOScalar_pushed stop clobbering the string and should
PerlIOScalar_open do it instead? Perhaps. But that would be a bigger
change, and we are supposed to be in code freeze right now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
using Eric Brine’s function.
|
| | |
|
| |
|
|
|
|
|
| |
It used to crash if the PVX buffer happened to be null.
If the PVX buffer happened to be left over from before,
it would use that instead of the numeric value, even for
!SvPOK scalars.
|
| |
|
|
| |
Otherwise, it won’t work with an overloaded object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we get assertion failures.
In fact, since seeking might be just for reading, we can’t coerce and
SvGROW either.
In fact, since the scalar might be modified between seek and write,
there is no *point* in SvGROW during seek, even for SvPOK scalars.
PerlIO::scalar assumes in too many places that the scalar it is using
is its own private scalar that nothing else can modify. Nothing could
be farther from the truth.
This commit moves the zero-fill that usually happens when seeking past
the end from seek to write. During a write, if the current position
is past the end of the string, the intervening bytes are zero-filled
at that point, since the seek hasn’t done it.
|
| | |
|
| |
|
|
|
| |
This is a signedness problem that ffe0bb5ab did not take into account.
(STRLEN)-10 > 0 returns true for me.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code in PerlIO-scalar that implements the open $fh, '>' \$buffer
feature did not, apart from accidentally, support get/set magic and thus
tied buffers. This patch remedies that: mostly by just blindly sprinkling
SvGETMAGIC/SvSETMAGIC about, rather than doing any deep analysis and
understanding of the code. One main change I did was to add a
PerlIOScalar_read() function, rather than rely on the default behaviour
(which implements it in terms of PerlIOScalar_get_ptr() etc), since that
approach had a tendency to call FETCH multiple times
|
| |
|
|
|
|
|
|
|
|
|
| |
Inspired by, and in parts borrows from, Schwern's branch on github, but takes a
slightly different approach in places.
Not quite perfect yet - ext/File-Glob still runs from t, at least one FIXME
needs fixing, and the changes to dual-life modules' tests need to be filtered
back upstream, and possibly modified to suit their respective authors.
But it works.
|
| |
|
