BrowserUk,
While $a and $b shouldn't have anything to do with @_, let me explain anyway:
- The 1st time the function is called with no arguments, $i become 0 to compare the first value of the array.
- If the values of both arrays are equal at index $i, $_[0] is incremented by 1 which auto-vivifies into existence if necessary
- When goto &sub is invoked subsequently, @_ has a value which is used for $i
After explaining, I verified that $_[0] is behaving correctly in the b0rk version using the print statements. It still doesn't explain why $a and $b are undefined on the second invocation or why it blows up?
| [reply] |
You miss my point. I'm not talking about $a & $b.
When the comparator is first called, if no parameters are passed, then @_ should be empty and $_[0] is "undefined". That's not undefined, but undefined in the non-useful, undefinable, implementation dependant, DO NOT USE sense.
$_[0] obviously is pointing (aliasing) somewhere, but where?
My best guess is that @_ contains the contents of the previous stack frame. Ie. the contents of @_ when the comparator is called, are the same as those passed to the function that is calling the comparator. which would be sort.
In which case, you are probably incrementing the address of the comparator itself--which would at least explain why it blows up!
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
BrowserUk,
You miss my point. I'm not talking about $a & $b.
I know, but that is where I can actually see a problem, not with @_.
When the comparator is first called, if no parameters are passed, then @_ should be empty and $_[0] is "undefined".
Yep, spot on. I auto-vivify $_[0] the first time it is called (which works great).
In which case, you are probably incrementing the address of the comparator itself
I am only vaguely getting at what you are trying to say here. The value of $_[0] is correctly being auto-vivified, incremented, and preserved between calls. I would think if it were the address of the comparator itself getting incremented then the second call wouldn't be possible.
I am not saying you are wrong because I definately respect your knowledge. I am just saying that nothing in any of my tests lead me to believe something is a miss with @_. The only thing that isn't behaving correctly is $a and $b. Even if it was with @_ - I still don't see how sort routine @list and sort { routine() } @list would make that much of a difference.
| [reply]
[d/l]
[select] |