On Sun, Aug 08, 2010 at 05:18:13PM -0700, Father Chrysostomos wrote: > # New Ticket Created by Father Chrysostomos > # Please include the string: [perl #77094] > # in the subject line of all future correspondence about this issue. > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=77094 > > > > $ perl -le 'printf("a\n" =~ /b/)' > a > > That is very strange, to say the least. I *think* that it's a bug, and that it's a bug in stack handling. In that the match runs in list context, so should return an empty list, and then printf should behave as for an empty list: $ ./perl -Dts -we 'printf("a\n" =~ /b/)' => (-e:1) null => (-e:1) const(PV("a\n"\0)) => PV("a\n"\0) (-e:1) stringify EXECUTING... => (-e:0) enter => (-e:0) nextstate => (-e:1) pushmark => * (-e:1) const(PV("a\n"\0)) => * PV("a\n"\0) (-e:1) match => * (-e:1) prtf a => SV_YES (-e:1) leave Compare with print, which does indeed print nothing: $ ./perl -Dts -we 'print("a\n" =~ /b/)' => (-e:1) null => (-e:1) const(PV("a\n"\0)) => PV("a\n"\0) (-e:1) stringify EXECUTING... => (-e:0) enter => (-e:0) nextstate => (-e:1) pushmark => * (-e:1) const(PV("a\n"\0)) => * PV("a\n"\0) (-e:1) match => * (-e:1) print => SV_YES (-e:1) leave But I don't know why this is, or whether there are any other listops that can be used to trigger the problem. hmm, and I *think* that we have a documentation bug, in that $ ./perl -we 'printf' Use of uninitialized value $_ in printf at -e line 1. yet nowhere that I can find is it documented that printf with no arguments defaults to using $_ [Thinking out loud, is that the problem - somehow the match is setting $_, but not resetting it] Nicholas ClarkThread Previous | Thread Next