| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Make sure dist/IO is not using indirect
calls.
|
| | |
|
| |
|
|
|
| |
Bugtracker and repo now point at perl/perl5. Hopefully this will
encourage people to report IO bugs there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-implement getline() and getlines() as XS code.
The underlying problem that we're trying to solve here is making
getline() and getlines() in IO::Handle respect the open pragma.
That bug was first addressed in Sept 2011 by commit 986a805c4b258067:
Make IO::Handle::getline(s) respect the open pragma
However, that fix introduced a more subtle bug, hence this reworking.
Including the entirety of the rest of that commit message because it
explains both the bug the previous approach:
See <https://rt.cpan.org/Ticket/Display.html?id=66474>. Also, this
came up in <https://rt.perl.org/rt3/Ticket/Display.html?id=92728>.
The <> operator, when reading from the magic ARGV handle, automatic-
ally opens the next file. Layers set by the lexical open pragma are
applied, if they are in scope at the point where <> is used.
This works almost all the time, because the common convention is:
use open ":utf8";
while(<>) {
...
}
IO::Handle’s getline and getlines methods are Perl subroutines
that call <> themselves. But that happens within the scope of
IO/Handle.pm, so the caller’s I/O layer settings are ignored. That
means that these two expressions are not equivalent within in a
‘use open’ scope:
<>
*ARGV->getline
The latter will open the next file with no layers applied.
This commit solves that by putting PL_check hooks in place in
IO::Handle before compiling the getline and getlines subroutines.
Those hooks cause every state op (nextstate, or dbstate under the
debugger) to have a custom pp function that saves the previous value
of PL_curcop, calls the default pp function, and then restores
PL_curcop.
That means that getline and getlines run with the caller’s compile-
time hints. Another way to see it is that getline and getlines’s own
lexical hints are never activated.
(A state op carries all the lexical pragmata. Every statement
has one. When any op executes, it’s ‘pp’ function is called.
pp_nextstate and pp_dbstate both set PL_curcop to the op itself. Any
code that checks hints looks at PL_curcop, which contains the current
run-time hints.)
The problem with this approach is that the (current) design and implementation
of PL_check hooks is actually not threadsafe. There's one array (as a global),
which is used by all interpreters in the process. But as the code added to
IO.xs demonstrates, realistically it needs to be possible to change the hook
just for this interpreter.
GH #14816 has a fix for that bug for blead. However, it will be tricky (to
impossible) to backport to earlier perl versions.
Hence it's also worthwhile to change IO.xs to use a different approach to
solve the original bug. As described above, the bug is fixed by having the
readline OP (that implements getline() and getlines()) see the caller's
lexical state, not their "own". Unlike Perl subroutines, XS subroutines don't
have any lexical hints of their own. getline() and getlines() are very
simple, mostly parameter checking, ending with a one line that maps to
a single core OP, whose values are directly returned.
Hence "all" we need to do re-implement the Perl code as XS. This might look
easy, but turns out to be trickier than expected. There isn't any API to be
called for the OP in question, pp_readline(). The body of the OP inspects
interpreter state, it directly calls pp_rv2gv() which also inspects state,
and then it tail calls Perl_do_readline(), which inspects state.
The easiest approach seems to be to set up enough state, and then call
pp_readline() directly. This leaves us very tightly coupled to the
internals, but so do all other approaches to try to tackle this bug.
The current implementation of PL_check (and possibly other arrays) still
needs to be addressed.
|
| | |
|
| | |
|
| |
|
|
|
| |
Even with ppport.h, providing a dual life IO that supports 5.6.2 is impractical.
Given the toolchain policy of 5.8.1, we don't think this is a significant change
|
| |
|
|
|
|
|
| |
Whenever a magical/tied scalar which dies upon read was passed to _poll()
temporary buffer for events was not freed.
Adapted from a patch by Sergey Aleynikov <sergey.aleynikov@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
I didn't update base.pm since that seems more likely to be loading
modules *expected* to be in the current directory. Opinions
welcome.
|
| |
|
|
|
|
|
|
|
|
|
| |
perl: IO.xs:322: XS_IO__Poll__poll: Assertion
`PL_valid_types_PVX[((svtype)((_svpvx)->sv_flags & 0xff)) & 0xf]'
failed.
This is because NEWSV(…, 0) returns undef, with a grabage pointer in
the PV slot. This doesn't seem to matter in practice, since nothing
actually dereferences the pointer when nfds is zero, but to be safe we
should pass in _some_ valid pointer, so just use the SV* itself;
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove (almost all) direct access to the op_sibling field of OP structs,
and use these three new macros instead:
OP_SIBLING(o);
OP_HAS_SIBLING(o);
OP_SIBLING_set(o, new_value);
OP_HAS_SIBLING is intended to be a slightly more efficient version of
OP_SIBLING when only boolean context is needed.
For now these three macros are just defined in the obvious way:
#define OP_SIBLING(o) (0 + (o)->op_sibling)
#define OP_HAS_SIBLING(o) (cBOOL((o)->op_sibling))
#define OP_SIBLING_set(o, sib) ((o)->op_sibling = (sib))
but abstracting them out will allow us shortly to make the last pointer in
an op_sibling chain point back to the parent rather than being null, with
a new flag indicating whether this is the last op.
Perl_ck_fun() still has a couple of direct uses of op_sibling, since it
takes the field's address, which is not covered by these macros.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This dual-lived module has not been able to be compiled on releases
earlier than 5.10.1 since, I believe, that release, and not outside of
blead since commit 6f2d5cbc in the 5.19 series, both due to using macros
that were not backported.
This commit suitably defines the current missing macro when it isn't
available.
|
| |
|
|
|
|
| |
PerlIO_unread() returns SSize_t, although from its sparse documentation
it doesn't seem that it would ever return a negative value. So cast away
the 'comparison between signed and unsigned integer' warning.
|
| |
|
|
|
|
|
| |
This removes a macro not yet even in a development release, and splits
its calls into two classes: those where the input is a byte; and those
where it can be any unsigned integer. The byte implementation avoids a
function call on EBCDIC platforms.
|
| |
|
|
| |
For: RT #116479
|
| |
|
|
|
|
|
| |
ungetc() had no knowledge of UTF-8. This patch adds it.
The committer fleshed out the author's code to make a patch, making
a few small changes.
|
| | |
|
| |
|
|
| |
cmpVERSION doesn't pick this up - should it?
|
| |
|
|
|
|
|
| |
This allows sync() to be called on directory handles.
Originally supplied as a diff, applied and updated to pass tests by
Tony Cook.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See <https://rt.cpan.org/Ticket/Display.html?id=66474>. Also, this
came up in <https://rt.perl.org/rt3/Ticket/Display.html?id=92728>.
The <> operator, when reading from the magic ARGV handle, automatic-
ally opens the next file. Layers set by the lexical open pragma are
applied, if they are in scope at the point where <> is used.
This works almost all the time, because the common convention is:
use open ":utf8";
while(<>) {
...
}
IO::Handle’s getline and getlines methods are Perl subroutines
that call <> themselves. But that happens within the scope of
IO/Handle.pm, so the caller’s I/O layer settings are ignored. That
means that these two expressions are not equivalent within in a
‘use open’ scope:
<>
*ARGV->getline
The latter will open the next file with no layers applied.
This commit solves that by putting PL_check hooks in place in
IO::Handle before compiling the getline and getlines subroutines.
Those hooks cause every state op (nextstate, or dbstate under the
debugger) to have a custom pp function that saves the previous value
of PL_curcop, calls the default pp function, and then restores
PL_curcop.
That means that getline and getlines run with the caller’s compile-
time hints. Another way to see it is that getline and getlines’s own
lexical hints are never activated.
(A state op carries all the lexical pragmata. Every statement
has one. When any op executes, it’s ‘pp’ function is called.
pp_nextstate and pp_dbstate both set PL_curcop to the op itself. Any
code that checks hints looks at PL_curcop, which contains the current
run-time hints.)
|
| | |
|
| |
|
|
| |
Also do the same in some of its error messages. This fixes CPAN RT#65836.
|
| |
|
|
|
| |
Core-only modules that have changed from v5.13.7, and dual-life modules
that have changed from v5.13.7 and didn't show up in earlier passes.
|
| | |
|
| | |
|
| |
|
