MSC02-PL. Run programs with full warnings and strict checking

Perl provides several mechanisms for warning the user about potential problems with the program. The use warnings pragma turns on a default set of warnings for the Perl runtime to produce should it detect questionable code. The -w command-line argument serves the same purpose. It is considered so useful that the perl(1) manpage [Wall 2011] dryly notes the first bug in Perl is that:

The -w switch is not mandatory.

The use warnings pragma must be used in all Perl code.

One of the modules that Perl provides for additional safety is the strict module. It identifies programming constructs that are likely to be errors, such as unqualified and undeclared variables (that might be typos), dangerous references, and unqualified subroutine names. The use strict pragma must be used in all Perl code.

However, occasionally there is a need to disable warnings or strictness for some code that may look strange, but is actually correct. The -w switch cannot enable or disable particular warnings on particular ranges of code. When a particular warning or strict checking must be disabled, the no warnings or no strict pragmas should be used in as minimal a scope as possible. They should also disable the specific warning or strictness checker that would trigger a warning or fatal error, rather than disable all checks.

Noncompliant Code Example (warnings)

This noncompliant code example contains code that produces an unchecked warning.

use warnings;
use strict;

my %days = ("Sunday"    => 'pray',
            "Monday"    => 'work',
            "Tuesday"   => 'work',
            "Wednesday" => 'work',
            "Thursday"  => 'work',
            "Friday"    => 'work',
            "Saturday"  => 'rest');

sub what_to_do {
  my $day = shift;
  if ($days{$day} eq 'work') {
    return 'work hard';
  }
  if (exists $days{$day}) {
    return $days{$day};
  } else {
    return "do nothing";
  }
}


my $task = what_to_do('tomorrow');
print "Prepare to $task\n";

This code produces the output:

Use of uninitialized value within %days in string eq at ./example.pl line 16.
Prepare to do nothing

Noncompliant Code Example (warnings)

This noncompliant code example attempts to suppress the particular warning printed.

use warnings;
use strict;
no warnings 'uninitialized';

my %days = ("Sunday"    => 'pray',
# ...

Unfortunately while this does correctly suppress the warning message, it has the undesired effect of suppressing the warning message throughout the entire program. This has the likely effect of suppressing the warning in other lines of code that are not known to be correct.

Compliant Solution (warnings)

This compliant solution suppresses the warning in as minimal a scope as possible. Because the uninitialized warning is suppressed only inside the what_to_do subroutine, other regions of the code can still generate this warning.

sub what_to_do {
  my $day = shift;
  no warnings 'uninitialized';
  if ($days{$day} eq 'work') {
    return 'work hard';
  }
  if (exists $days{$day}) {
    return $days{$day};
  } else {
    return "do nothing";
  }
}

Noncompliant Code Example (strict)

This noncompliant code example contains code that references a nonexistant variable.

use strict;
use warnings;

our $sunday    = 'pray';
our $monday    = 'work';
our $tuesday   = 'work';
our $wednesday = 'work';
our $thursday  = 'work';
our $friday    = 'work';
our $saturday  = 'rest';

sub what_to_do {
  my $day = shift;
  no warnings 'uninitialized';
  if ($$day eq 'work') {
    return 'work hard';
  }
  if (defined $$day) {
    return $$day;
  } else {
    return "do nothing";
  }
}


my $task = what_to_do('tomorrow');
print "Prepare to $task\n";

The strict pragma catches the improper reference and aborts the program, producing the following error message:

Can't use string ("tomorrow") as a SCALAR ref while "strict refs" in use at ./example.pl line 19.

Noncompliant Code Example (strict)

This noncompliant code example disables the strict pragma, thus producing proper output. However, strict-ness is suppressed throughout the entire program.

use warnings;
use strict;

no strict 'refs';

our $sunday    = 'pray';
# ...

This code produces the output:

Prepare to do nothing

This may be considered correct, but the code works by referencing a nonexistent variable $tomorrow.

Compliant Solution (strict)

This compliant solution suppresses the strict-ness checking to as minimal a scope as possible. Because the strict checking is suppressed only inside the what_to_do subroutine, other regions of the code can still checked for strict compliance.

sub what_to_do {
  my $day = shift;
  no warnings 'uninitialized';
  no strict 'refs';
  if ($$day eq 'work') {
    return 'work hard';
  }
  if (defined $$day) {
    return $$day;
  } else {
    return "do nothing";
  }
}

Risk Assessment

Suppressing warnings can mask problems that would otherwise be quickly recognized and fixed.

Related Guidelines

CERT C Secure Coding Standard: MSC00-C. Compile cleanly at high warning levels

CERT C++ Secure Coding Standard: MSC00-CPP. Compile cleanly at high warning levels

Automated Detection

Bibliography

[Conway 05] pg. 433
[CPAN] Elliot Shank, Perl-Critic-1.116 TestingAndDebugging::ProhibitNoStrict,
TestingAndDebugging::ProhibitNoWarnings,
TestingAndDebugging::ProhibitProlongedStrictureOverride,
TestingAndDebugging::RequireUseStrict
[Wall 2011] perl strict warnings

EXP30-PL. Do not use deprecated or obsolete functions      02. Expressions