Front page | perl.perl5.porters |
Postings from June 2012
On Sun Dec 11 16:29:57 2011, alh wrote: > On Sun, Dec 11, 2011 at 7:23 PM, Father Chrysostomos via RT < > perlbug-followup@perl.org> wrote: > > > On Sun Dec 11 14:26:00 2011, alh wrote: > > [...] > > > The reason I'm not sure if this is the right fix or not (or maybe it is > > > and it's unfortunate that it is) is that it seems we rely too much on > > > the coder having to know when to set/clear PL_last_lop and > > PL_last_lop_op. > > > > > > These don't appear to be documented well so I'm not absolutely certain > > > of their purpose, when they are used, etc etc, (and it gets even more > > > confusing with oldbufptr and oldoldbufptr...) > > > > > > If someone could shed some light on these, that'd be awesome. > > > > That looks correct to me, but I don’t think I understand this code any > > better than you do. > > > > What really bugs me about this piece is: > > /* See if it's the indirect object for a list operator. */ > > if (PL_oldoldbufptr && > PL_oldoldbufptr < PL_bufptr && > (PL_oldoldbufptr == PL_last_lop > || PL_oldoldbufptr == PL_last_uni) && > /* NO SKIPSPACE BEFORE HERE! */ > (PL_expect == XREF || > ((PL_opargs[PL_last_lop_op] >> OASHIFT)& 7) == > OA_FILEREF)) > > We enter this block if PL_oldoldbufptr == PL_last_lop or PL_last_uni, but > then we still match if PL_opargs[PL_last_lop_op]. > > That just doesn't seem right... > > -- Matthew Horsfall (alh) Seems like this patch is stuck because no one can quite be sure that it'll work right. So who do we have to bug for a CPAN smoke? : D --hugmeir --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=16249Thread Next