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=107008Thread Previous | Thread Next