Re: -w in production environment

[tachyon]

Eliminating -w is one option that will work and is reasonable if you have completely debugged all the code...If you find a reliable method please tell me how! Another option is to initialise all your values. It depends on how your script is structured as to how you do this. Say you are using CGI.pm, here is what you usually find at the top of my scripts:

#!/usr/bin/perl -wT
use strict;
use CGI;
my $q = new CGI;

my $var = $q->param('var') || '';
untaint(\$var);

# warning do not do this
my @ary = $q->param('options') || ();
# this kills the array return of CGI.pm

If you use param queries directly you can do this to define all undefined values:

my @fields = qw(foo bar baz);
for (@fields) {
    $q->param($_,'') unless defined $q->param($_);
}

This iterates over the field names an pushes a null string into the value if it is not defined. You can use the same method for a hash:

my @fields = qw (foo bar baz);
for (@fields) {
    $USER{$_} = '' unless defined $USER{$_};
}

Use strict does have an overhead (a very small overhead) - try benchmarking if you are really worried and execution speed is everything. Use mod perl in this case! The reason for leaving use strict and -w active is that your code *will* be modified one day, perhaps by you, perhaps not. If they are active no one has to to remember to reactivate them. If you must kill them comment them out rather than erase them entirely with a note that the should be used for testing modifications to the code.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[tye]

Use strict does have an overhead

?? Well, that is pretty darn misleading. use strict has a very, very tiny overhead such that most people that I respect and who I've heard weigh in on the subject feel that the work of adding and removing strict between testing and production (and more importantly, the risk of forgetting to add it back in each time changes are made) outweigh the cost by a wide margin.

Taint checking is also something that should not be disabled in production (even more so than strict).

Warnings, however, are much easier to justify removing from production. Perhaps the best situation would be to keep warnings enabled but have a separate infrastructure for collecting warnings information and making sure the volume of information can't become a burden.

But if you don't create a separate infrastructure for warnings, I'd definitely turn them off in production.

        - tye (but my friends call me "Tye")

[tachyon]

Hi, it's not misleading at all. *Every* operation in Perl has an overhead - including use strict. As the question was "does use strict have an overhead?" the answer is/was correct. I then went on to suggest benchmarking and mod Perl if speed was the critical issue and then additionally suggest reasons not to disable use strict and -w....as you reiterated....

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print