File handles are traditionally package variables that represent file descriptors. Unlike other variables, file handles are typically not prefixed with punctuation. All barewords are subject to being interpreted by the parser differently than the developer intended, but bareword file handles are particularly fraught with peril. Consequently, file handles should never be stored as barewords.

Noncompliant Code Example

Suppose we maintain some simple code that makes the mistake of using bareword file handles.

open( GOOD, "<", "good.txt");
my $good_data = <GOOD>;
print "GOOD: $good_data";
print "\n";
{
  open( BAD, "<", "bad.txt");
  my $bad_data = <BAD>;
  print "BAD: $bad_data";
  print "\n";
}
my $more_good_data = <GOOD>;
print "MORE GOOD: $more_good_data";

This code works as expected. It reads and prints a line of good text, followed by a line of bad text, followed by a second line of good text.

But during maintenance, someone (undoubtedly with the best of intentions) adds this function:

sub BAD {return GOOD;}

This function completely changes the behavior of the subsequent code. The BAD bareword is now interpreted as a subroutine call, not a file handle.

The program, as before, first opens good.txt, storing it in the GOOD file handle, which is a package variable. It next opens bad.txt, but instead of storing the descriptor in a BAD file handle, it stores the descriptor in the file handle returned by the BAD() subroutine, which returns GOOD. Consequently, the GOOD file handle now points to the descriptor for bad.txt, not good.txt.

The program then tries to read from the BAD file handle, but this attempted read produces nothing because this file handle was never actually opened. Nonetheless, the program then reads a line from the GOOD file handle and echoes it—which turns out to be from bad.txt rather than good.txt.

Compliant Solution

This compliant solution protects the file descriptors by using anonymous scalars rather than bareword file handles.

sub BAD {return GOOD;}

open( my $GOOD, "<", "good.txt");
my $good_data = <$GOOD>;
print "GOOD: $good_data";
print "\n";
{
  open( my $BAD, "<", "bad.txt");
  my $bad_data = <$BAD>;
  print "BAD: $bad_data";
  print "\n";
}
my $more_good_data = <$GOOD>;
print "MORE GOOD: $more_good_data";

Consequently, the original behavior of this program is restored. Because the $BAD variable is declared with my, it is a lexical variable rather than a package variable and is unaffected by the BAD subroutine. So this program once again prints two lines from the good.txt file and one from the bad.txt file, and never confuses the two.

Exceptions

FIO00:EX0: The following barewords are built-in to Perl and are exceptions to this rule:

ENV

STDIN

INC

STDOUT

ARGV

STDERR

ARGVOUT

_

SIG

DATA

Risk Assessment

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

FIO00-PL

medium

probable

low

P12

L1

Automated Detection

Tool

Diagnostic

Perl::Critic

InputOutput::ProhibitBarewordFileHandles

Bibliography

 


4 Comments

  1. Anonymous

    The DATA, ARGV, and ARGVOUT file handles are other built-in bareword filehandles.

    1. True. Added these to EX0, as they are safe to use as filehandlers.

      1. I might be missing it, but the DATA filehandle is still not included in the list of exceptions.

        1. I was missing it. (smile) Fixed.