in reply to Re: Use of uninitialized value in substr
in thread Use of uninitialized value in substr

But there is no need for ops to "grovel through the optree at runtime".


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
  • Comment on Re^2: Use of uninitialized value in substr

Replies are listed 'Best First'.
Re^3: Use of uninitialized value in substr
by ikegami (Patriarch) on May 03, 2010 at 20:24 UTC
    While his "at runtime" is a straw man, it's not as simple as you imply it is. A lot more than undef returns PL_sv_undef. For example, `foo` (that you insisted is completely unrelated to undef) also returns PL_sv_undef.
    #! perl -slw use 5.010; use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'uCmp', CLEAN_AFTER_BUILD => 0; bool uCmp( SV* t ) { return (bool)( t == (&PL_sv_undef) ); } END_C print 'explicit undef: ', uCmp( undef ) ? 1 : 0; print '`foo`: ', uCmp( scalar(`foo`) ) ? 1 : 0; __END__ explicit undef: 1 Can't exec "foo": No such file or directory at a.pl line 14. `foo`: 1

      And you think that a programmer who

      1. Invokes a non-existant command,
      2. wrapped in scalar,
      3. as the fourth argument to substr

      And gets the target substring replaced by nothing--without a warning that the fourth parameter was undefined--is going to ignore the

      Can't exec "foo": No such file or directory at a.pl line 14.

      warning and throw their hands in the wondering what went wrong?


      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.

        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.

      What am I missing here? Perl can decide what to do at compile time. In the case of substr perl could just replace undef with '' behind the scenes. Though personally I think '' is easier to understand (and easier to type).

      Elda Taluta; Sarks Sark; Ark Arks

        Nothing, I said exactly the same thing you did.