in reply to Use of uninitialized value in substr

Another way to avoid the warning is to locally disable warnings within a block. Maybe more Perlish: 
use strict;
use warnings;

my $s = 'fred';;
{
    no warnings;
    substr $s, 1,2,undef;;
}
print $s;;

[download]

Update: BrowserUk is correct ... I am not licensed to assess if one solution is more Perlish than another. The judge will instruct the jury to ignore that remark :)

Replies are listed 'Best First'.
Re^2: Use of uninitialized value in substr
by BrowserUk (Patriarch) on May 03, 2010 at 12:57 UTC

    Hm. I'm not sure I'd call having to wrap every use of substr in a no warnings block, more perlish. I'd just go with '' and have done with it.

    It just strikes me that as substr is a built-in, it could accept undef as a legitimate parameter.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      It does. Some builtins just warn when used with undef, but you requested that yourself (by typing use warnings;). So what?

      Inserting an undef null-string is basically the same as interpolating an undefined variable into a string - do you think that shouldn't warn either?

[reply]
[d/l]

        It seems to me that there is a considerable difference between using a variable who current value is undef, and using undef explicitly.

        And that, at least for built-ins that have (or could have) access to the information to know the difference, they could (and should?) be treated differently.

        If I pass a varible who's current value is undef, there is a possibility that it is an accident of bad flow control. If I pass undef explicitly, I've chosen to do so.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      It just strikes me that as substr is a built-in, it could accept undef as a legitimate parameter.
      Actually, it's only build-ins (be them functions or operators) that trigger this warnings. Which you have to actually enable to see them.

      Why shouldn't this warn, but any of the following should: 

      $x = 3 + undef;
printf "%s", undef;
undef =~ /./;

      [download]
      The warning is to catch cases like: 
      $x = expression unexpectedly returning undef.
substr $y, 1, 2, $x;

      [download]
      One could argue that using a literal undef shouldn't trigger the warning (after all, then the programmer is explicit), but I don't think that information is easily available at the moment the warning is triggered. And the programmer may as well write "" or 0 anyway, saving some keystrokes.
[reply]
[d/l]
[select]

      Then turn off just this warning. It causes more problems than it solves.

      use warnings;
no warnings 'uninitialized';

      [download]

      In this particular case though using '' seems cleaner.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

[reply]
[d/l]

In Section Seekers of Perl Wisdom