Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 64437
Status: resolved
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: rjray [...] blackperl.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.111
Fixed in: 1.114



Subject: InputOutput::RequireBriefOpen false-positive
The attached code snippet yields an "InputOutput::RequireBriefOpen" violation, despite the fact that the open and close are within 9 lines of each other (the default). Even with the "lines" parameter of that policy set as high as 20, the violation still appears. Randy -- """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Randy J. Ray Silicon Valley Scale Modelers: http://www.svsm.org rjray@blackperl.com randy.j.ray@gmail.com
Subject: briefopen.pl
#!/usr/bin/perl use strict; use warnings; use Carp 'croak'; my $file = shift; my ($fh, @lines); if (! open $fh, '<', $file) { croak "Error opening $file for reading: $!"; } @lines = <$fh>; if (! close $fh) { croak "Error closing $file after reading: $!"; } exit 0;
On Mon Jan 03 19:44:45 2011, RJRAY wrote: Show quoted text
> The attached code snippet yields an "InputOutput::RequireBriefOpen" > violation, despite the fact that the open and close are within 9 lines > of each other (the default). Even with the "lines" parameter of that > policy set as high as 20, the violation still appears. > > Randy
The problem at the moment is that InputOutput::RequireBriefOpen assumes that the open() and the close() are in the same lexical scope. I believe the usual idiom for what you are doing would be something like open my $fh, '<', $file or croak "Error opening $file for reading: $!"; @lines = <$fh>; close $fh or croak "Error closing $file after reading: $!"; but since this policy is not about enforcing that idiom, I present it only as a workaround, not as exoneration of the policy or criticism of your code. RT #56625 is a similar instance. I could swear that there was a discussion somewhere about how to address this, but it appears never to have gone beyond discussion.
The problem here was that the policy restricted its analysis to the scope which contained the open(). This is OK for 'open my $fh, ...', but is not necessarily correct if the file handle is declared (if at all) before the open(). The fix was to, if necessary, expand the search for a close() to the most-local scope that ends outside the allowed line count. This was committed as SVN revision 4045. RT #56625 turned out not to be as close to this case as I thought initially, so I just closed it.