Re^2: Use of uninitialized value in substr

Replies are listed 'Best First'.
Re^3: Use of uninitialized value in substr by moritz (Cardinal) on May 03, 2010 at 13:00 UTC
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]
Re^4: Use of uninitialized value in substr by BrowserUk (Patriarch) on May 03, 2010 at 13:17 UTC
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. RIP an inspiration; A true Folk's Guy	[reply]
Re^5: Use of uninitialized value in substr by moritz (Cardinal) on May 03, 2010 at 13:29 UTC
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. I'm not aware of that difference in any existing perl built-ins (except those which modify their arguments). Introducing such a difference would only lead to questions of the form "how can I change my code so that it acts as if it were a literal, not a variable?", and no real benefit. 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. ... and you've chosen to get the warning. I don't see why you should ever use a literal undef when you really should be using an empty string, and expect not to get a warning. I also don't see how undef would be more perlish than the empty string.	[reply]
Re^6: Use of uninitialized value in substr by almut (Canon) on May 03, 2010 at 13:53 UTC
Re^6: Use of uninitialized value in substr by BrowserUk (Patriarch) on May 03, 2010 at 13:55 UTC
Re^3: Use of uninitialized value in substr by JavaFan (Canon) on May 03, 2010 at 13:11 UTC
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]
Re^3: Use of uninitialized value in substr by Jenda (Abbot) on May 03, 2010 at 14:23 UTC
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]