I would not have considered cases 2, 3 or 6 false positives
Why not? A warning would be issued for complete, accurate, functioning code. That's the very definition of a false positive.
#2 ignores one of the function's return values. There are other ways of doing it, but there's nothing wrong with that way.
#3 implements creates an empty file.
#6 is used in creating inside out objects.
#1 uses $foo++
No. As far as Perl is concerned, '$foo++' might as well be 'print "Hello World"' when the program is compiled. $foo is only seen long after the warning has been issued, when the eval is executed.
#4 in theory will see $lock checked at least once inside do_stuff_that_needs_the_lock()
No. It's not passed to do_stuff_that_needs_the_lock (which would be using it twice).
#5 passes $tree to new()
Yeah, but what about $sentinel?
#4 and #5 are both examples of Resource Acquisition Is Initialization objects where the functionality exists solely in the constructor and the (implicitly called) destructor.
In reply to Re^3: Warnings on unused variables?
by ikegami
in thread Warnings on unused variables?
by AZed
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |