To me, all the four examples you provide return a perfectly valid result, or at least exactly the result I would expect. So nothing wrong with them IMHO.
Contrary to the OP's question, which really appears to be displaying an actual bug.
Update: Of course, I meant: all the four examples as originally provided by sundialsvc4 return a perfectly valid result. The last example, as it stand now, does no longer return a valid result, but that example was changed by its author almost 24 hours after I posted my comment above. Fortunately, hippo provided a copy-and-paste of the last example as it was originally posted and as it was when I answered, thus showing that this comment was right at the time.
| [reply] |
| [reply] |
The corrected example merely repeats the originally reported bug.
Certainly won’t be the first time that an optimizer produced incorrect results. Delphi-6 had a similar bug, too, that vexed me for a time. It is almost a general rule-of-thumb that, if calling any function that modifies one of its inputs, do not assign the result back to the same variable. Optimizers like to remove “unnecessary” loads and stores, and they like to re-order things, and it becomes a gray area. Just put the result down someplace else.
| |
$ perl -e 'my $v = "foo\n"; $foo = chomp($foo); print "$foo\n";'
0
What would you expect this to print given that $foo is undefined when chomped? I consider this output to be entirely the correct result of that code. Why would you have it differ and in what way?
| [reply]
[d/l]
[select] |
Your post doesn't add anything new to this thread. Mine adds a correction to your last paragraph
The first case is what is used 99% of the time, because “the function is an English verb.” Effectively, it is an imperative statement. You want to “chomp” a string, and it does. If you use the implied-variable "$_" it also produces the documented result, even though nobody actually does that. If you use your own variable, it does not. Given that you probably don’t have the latest Perl installed on your machine and probably can’t change it, you have to code-around bugs like these. If the function is a verb, use it as a verb only.
which is wrong. "If you use your own variable, it does not." Of course it does! It is perfectly ok to use chomp on "your own variable." It would be interesting to find why assignment to $_ works, but fails with $line - but you don't even try, you just post the bizarre statement that this happens because “the function is an English verb.”
And then
If the function is a verb, use it as a verb only.
Wait, what?!? Where did you get that from? Where in the perl docs is stated, that "English Verbs" only behave correctly on "implied $_"? So we should never use a "own variable" with print,split, shift, unshift and so on?
See, sundialsvc4, these assertions which you just pull out from your pool of speculations, not knowledge, are what many monks here annoy and what they detest and condemn as misleading, specially to newbies, even if they make for a good laugh for experienced perlers.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply]
[d/l]
[select] |
