Re^5: Use of uninitialized value in substr

wrapped in scalar,

Not only is there nothing odd with using scalar, substr imposes a scalar context on its fourth arg.

Invokes a non-existant command,

Pointless unless you're arguing we should get rid of the warning entirely. It's an example of a function that returns an error.

As for Can't exec, I didn't know about that warning when I came up with the example earlier.

The point that using PV_sv_undef isn't sufficient to detect an explicit undef stands. I didn't say it wasn't possible to detect an explicit undef, I just said checking PV_sv_undef doesn't cut it.

Comment on Re^5: Use of uninitialized value in substr Select or Download Code

Replies are listed 'Best First'.
Re^6: Use of uninitialized value in substr by BrowserUk (Patriarch) on May 03, 2010 at 21:26 UTC
The point is, it is an extremely contrived example. And one that does not further the discussion. To arrive at the point where the absence of the 'uninitialised' warning could possibly be seen as bad, a different, more relevant and diagnostic warning is produced. So, in that case, the suppression of the former is not a problem. 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^7: Use of uninitialized value in substr by ikegami (Patriarch) on May 03, 2010 at 23:32 UTC
I don't know what's contrived about substr(..., `$cmd`) [download] But fine, surely the following isn't contrived `substr(..., pop(@a))` [download]	[reply] [d/l] [select]