wolis has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

A line of code from a perl script I have inherited is giving me the wonderful warning: 

Use of uninitialized value in string ne ...

[download]
The line looks like this: 
 if ($this_loc ne $last_loc) {

[download]
Searhing perlmonks shows quite clearly that one of the two variable is undefined. So I feel well equipted to solve this problem.

Since $this_loc is read from a database and $last_loc is simply the value of the last $this_loc I deduce that its $this_loc which is getting undefined while being read from the database.

So my trival question is: If you define the variable at the start of the code: 

my $this_loc = -111;

[download]
..as they have done at the start of the script.. how can the act of updating the contents of the value clobber this variable? 
 $this_loc = $rowDivData->{LOCATION_ID};

[download]
Would it not just contain a null string if nothing was found in the database - but still exist? 
 ___
/\__\ Creative Object World (COW)
\/__/ www.wolispace.com/cow

[download]

Replies are listed 'Best First'.
Re: A bit more clarity on uninitialized value in string ne
by runrig (Abbot) on Jan 20, 2005 at 23:25 UTC
    Since $this_loc is read from a database...
    NULL values fetched from the database translate into undef values for perl. See the last example in Simple Examples in the DBI docs for a solution. Alternatively, you can set no warnings 'uninitialized'; locally for that block of code.
[reply]
[d/l]
Re: A bit more clarity on uninitialized value in string ne
by ysth (Canon) on Jan 20, 2005 at 23:27 UTC
    No, for historical reasons the error message is a lie; it really means the value is "undefined", not the variable "uninitialized". Perl has a special value undef which is usually used in an error situation. For instance, if the %$rowDivData hash doesn't have a LOCATION_ID key, or if the value for that key was set to undef, $this_loc will be undef.
[reply]
[d/l]
[reply]

        Ovid,

        You gotta pick your battles. This is undoubtedly a misleading (and often incorrect) error message. I think (and hope) that it would be difficult to find someone who disagrees with that. But "thoroughly irked"? That's when you need to pick your battles. XML::Twig crashing perl5.6 - that is thoroughly irksome. CGI::Session not saving the session because the only thing that changed was an expiry - that is irksome (but probably not thoroughly irksome). A misleading error message? That's something to open a formal bug report on (does p5p use a bugzilla or something?), take a deep breath, drink some nice tea, beer, or other beverage of choice, and move on. ;-)

[reply]
        I am aware of this and thoroughly irked by it. It would certainly be nice if Perl could disambiguate between the two. As it turns out, there might be information in perl about that, but there doesn't seem to be much interest in fixing this.
        Currently the internals of Perl can't be used to distinguish between an uninitialised value and a merely undef one. To make the core do so would involve adding an extra flag to all SVs and adding code to about every fourth line in sv.c to set or unset it as appropriate. And for very little gain.

        Okay, the warning is misleading: it's warning about the use of an undef value rather than un uninitialised one. We would change the warning text, but then that would probably break half the test suites on CPAN and everyone would hate us for it.

        Dave.

[reply]

        undef is how Perl designates that a variable is uninitialized. undef $var is how you declare that the variable is no longer initialized. $var= undef does the same thing.

        If you try to disinguish 'undef' from 'uninitialized', then you'd need a new way to deinitialize variables and an alternative for defined that would tell you if a variable was initialized.

        undef and defined are just Perl's methods of introspection about whether a variable is initialized. It is good that you can explicitly mark a variable as uninitialized and that you can programmatically check for initialization. Marking a variable as uninitialized can look like initializing the variable.

        I agree that using "uninitialized" instead of "undefined" in error messages is unfortunate. But they mean the same thing in Perl.

        - tye        

[reply]
[d/l]
[select]
Re: A bit more clarity on uninitialized value in string ne
by holli (Abbot) on Jan 20, 2005 at 23:26 UTC
    look at this code: 
    #!perl -w
use strict;
my $var = "111";
$var = undef;
print $var;

    [download]
    The output is "Use of uninitialized value in print at script.pl line 5.". That is because $var is first set to "111" and then to undef afterwards. Likely it is that what happens in your script, e.g. a subroutine you call can return undef.

    holli, regexed monk
[reply]
[d/l]
Re: A bit more clarity on uninitialized value in string ne
by dfaure (Chaplain) on Jan 20, 2005 at 23:36 UTC

    According to DBI documentation (Notation and Convention), $this_loc would contain undef.

    ____
    HTH, Dominique
    My two favorites:
    If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
    Bien faire, et le faire savoir...

[reply]

Back to Seekers of Perl Wisdom