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

Look. I can only reiterate the second paragraph of my response to your first non-contribution to this thread:

The real question is about making explicit undef semantically different from indirect undef; and therefore making it more powerful, and useful.

I do not believe for one second that you think that `foo` is in anyway equivalent to "explicit undef".

Nor do I believe that you--uniquely amongst the responders in this thread--cannot interpret the explicit use of undef in the OP, combined with the statement "The warning is easily avoided by using '' instead of undef,", to mean anything other than I am only concerning myself with the situation where undef is explicitly coded.

So that then requires that we ask ourselves: why do you keep trying to suggest that any situation where an undifined value could be passed accidently has any bearing at all upon this discussion? What do you hope to gain? What axe are you trying to grind?

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

Replies are listed 'Best First'.
Re^9: Use of uninitialized value in substr
by ikegami (Patriarch) on May 03, 2010 at 19:08 UTC

    I do not believe for one second that you think that `foo` is in anyway equivalent to "explicit undef".

    Both are means of producing the same value.

    Nor do I believe that you--uniquely amongst the responders in this thread--cannot interpret the explicit use of undef in the OP

    Nor should you. What wasn't clear is that you wanted to you only wanted to disable the warning when the undef function was used. In your mind, undef is some magical value. In mine, it's a function like any other.

    I don't know why you say I'm unique. moritz said said exactly what I did.

[reply]
[d/l]
      In your mind, undef is some magical value. In mine, it's a function like any other.

      Then my mind is right, and yours is wrong! 

      #! 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;

my $s;
print 'uninitalised lexical: ', uCmp( $s ) ? 1 : 0;

my @a;
print 'uninitalised array element: ', uCmp( $a[ 5 ] ) ? 1 : 0;

my %h;
print 'uninitalised hash value: ', uCmp( $h{fred} ) ? 1 : 0;

our $g;
print 'uninitalised global: ', uCmp( $g ) ? 1 : 0;


print 'Other unexplicit undef values: ', uCmp( `unknown_command` ) ? 1
+ : 0;

__END__
C:\test>uCmp
explicit undef: 1
uninitalised lexical: 0
uninitalised array element: 0
uninitalised hash value: 0
uninitalised global: 0
'unknown_command' is not recognized as an internal or external command
+,
operable program or batch file.
Usage: main::uCmp(t) at C:\test\uCmp.pl line 28.

      [download]
      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]
[d/l]
        I'm aware of PL_sv_undef and how it's used. It's besides the point. In Perl land, undef is undef is undef. There's only one case where I know where that doesn't hold (in open), and I believe that was a mistake (or a backwards compatibility solution).
[reply]
[d/l]

In Section Seekers of Perl Wisdom