Front page | perl.perl5.porters |
Postings from September 2016
On 13 September 2016 at 22:00, Todd Rinaldo via RT <perlbug-followup@perl.org> wrote: > On Tue Sep 13 12:14:27 2016, demerphq wrote: >> On 13 September 2016 at 21:06, Todd Rinaldo via RT >> <perlbug-followup@perl.org> wrote: >> > On Tue Sep 13 12:01:23 2016, demerphq wrote: >> >> >> >> We can and should audit for similar patterns, but my gut feeling is >> >> that this code is pretty unusual, as it is trying to extract the >> >> function part of a fully qualified name. >> >> >> > >> > S_parse_gv_stash_name is making a similar look ahead mistake with >> > name_cursor[1]. That looks messier to fix but it should probably be >> > another case or a committer should just go through and make the >> > corrections sans perlbug? >> >> A quick look didnt reveal to me any issues here. If you look at the >> way it uses name_em1 and name_end it looks fine. Can you point me more >> closely at the code you suspect? >> > > Yep. Apologies. I pulled the trigger too quick on that one. Yeah, well so did I with that premature push. :-) Anyway, I repushed my changes: cfb7367 fix #129267: rework gv_fetchmethod_pvn_flags separator parsing e2cace1 clean up gv_fetchmethod_pvn_flags: rename nsplit to last_separator d5ea0ef clean up gv_fetchmethod_pvn_flags: move origname init to function start 65308f8 clean up gv_fetchmethod_pvn_flags: introduce name_end I think the code is much easier to understand now. FC, I didnt really see a way to test for a string overrun via XS::APItest, maybe I didnt try hard enough tho. Can you think of something? (I think this ticket can be closed tho.) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next