update: after tobyinks 3rd update I see that order of operations plays a role, I still think you should perlbug it, because at least the perlop, and warnings, need to warn more about this ...
Documenting Auto-increment and Auto-decrement is great, but needs to warn about MORE, like this case, or foo($1,$2) <c>foo("$1","$2")
Even B::Lint doesn't warn about it
B::Concise shows no difference between the two
9 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 3 junk22:7) v:{ ->3
8 <@> print vK ->9
3 <0> pushmark s ->4
7 <1> entersub[t2] lKS/TARG,1 ->8
- <1> ex-list lK ->7
4 <0> pushmark s ->5
5 <$> const[PV "effect / 7ACV06"] sM ->6
- <1> ex-rv2cv sK/128 ->-
6 <#> gv[*butter] s ->7
| 9 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 3 junk33:7) v:{ ->3
8 <@> print vK ->9
3 <0> pushmark s ->4
7 <1> entersub[t2] lKS/TARG,1 ->8
- <1> ex-list lK ->7
4 <0> pushmark s ->5
5 <$> const[PV "effect / 7ACV06"] sM ->6
- <1> ex-rv2cv sK/128 ->-
6 <#> gv[*butter] s ->7
|
Even the mighty perlcritic doesn't warn about undefined behaviour
But I actually knew about this and forgot
warnings/lint/critic need to recognize and warn me cause I'll probably forget :)
It ought to be easy to recognize an unquoted $1 as a function argument and issue a warning , at least for perlcritic -- if that concise output is any indication, lint might be slightly harder
Maybe perltrap/Common Perl Pitfalls could also use some updating
This part below written before your butterjunkeffect update, on the approach to solving this problem
Ick :) Um, do you really want to find the cause, or do you want a better way to write it?
I'm not inclined to try debugging a program that hacks a tree as a string, I'm inclined to create a tree first (say an array of array or Tree ) and then navigate (calculate distance)
update: tobyink is probably right as to cause
Those rosalind newick trees could be drawn with ascii Dumping trees to a console.
|