Front page | perl.perl5.porters |
Postings from March 2012
On Wed Mar 21 20:20:44 2012, sprout wrote:
> On Wed Mar 21 18:49:00 2012, Hugmeir wrote:
> > > I’ve begun work on the patches following that. I need to ask Brian
> > > Fraser about
> > > <
> > > https://github.com/Hugmeir/gsoc-pad-utf8-
> > safety/commit/4929775f6218457e97e9c11e8b1fcfce20b6316f
> > > >.
> > > Unicode delimiters are not going to go into 5.16, so this patch is
> > > unnecessary for now, right?
> > >
> >
> > I would say throw it out, yes. The one thing it might have fixed
> > (unintendedly, and definitely without tests) is the error message in
> >
> > use open qw( :utf8 :std );
> > use utf8;
> > use 5.014;
> >
> > eval "q\x{FF01}asdasd\n\x{FF01}say 1";
> > say $@;
> >
> > But that can be properly addressed later.
>
> Er, that might explain why the tests added by 6961eeb7b3 (toke.c:
> S_missingterm cleanup) are failing for me. :-)
Yes, that patch for Unicode delimiter groundwork does fix those tests,
so it will go in.
Now a later patch (which seems totally unrelated) is causing something
bizarre:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c
0x002d073e in filter_call (my_perl=0x800000, idx=0, buf_sv=0x8789d0,
maxlen=0) at Call.xs:55
55 SV *my_sv = FILTER_DATA(idx);
(gdb) p my_perl->Iparser->rsfp_filters
$1 = (AV *) 0x0
(gdb) p my_perl
$2 = (PerlInterpreter *) 0x800000
(gdb) p ((PerlInterpreter *) 0x800000)->Iparser->rsfp_filters
$3 = (AV *) 0x882180
Has anyone ever seen anything like that? That expression produces a
different result when my_perl is replaced with its value.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=107008
Thread Previous
|
Thread Next