FAQ
Currently,

my $x = (1 .. 2);

throws an uninitialized warning when no file was ever read from, but
doesn't cite the undefined scalar at cause :

Use of uninitialized value in range (or flip) at -e line 1.

I found myself confused several times with that warning, since both 1
and 2 both look pretty much of the most defined kind to me - and this
even by knowing that it must have been caused by the undefinedness of $.
The attached patch makes it explicitely state "$.".

V.

Search Discussions

  • Jim Cromie at May 27, 2009 at 2:17 am

    +Use of uninitialized value $. in range (or flip) at - line 12.
    +Use of uninitialized value $. in range (or flip) at - line 14.
    Its certainly an improvement, insofar as it leaves a specific clue,
    but the average joe wont know that:
    $. is line-number on an input filehandle,
    so it must be magically going to stdin in scalar context ?????


    $ perl -wpe 'my $x = (1 .. 2);' /dev/null
    <no warning>
    did giving perl empty input fix the uninit-var connected to your $.
    explanation ?


    fwiw splain doesnt help (clarify the underlying $.) either:

    perl -we 'my $x = (1 .. 2)' 2> junk ; splain junk
    Use of uninitialized value in range (or flip) at -e line 1 (#1)
    (W uninitialized) An undefined value was used as if it were already
    defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
    To suppress this warning assign a defined value to your variables.

    To help you figure out what was undefined, perl will try to tell you the
    name of the variable (if any) that was undefined. In some cases it cannot
    do this, so it also tells you what operation you used the undefined value
    in. Note, however, that perl optimizes your program and the operation
    displayed in the warning may not necessarily appear literally in your
    program. For example, "that $foo" is usually optimized into "that "
    . $foo, and the warning will refer to the concatenation (.) operator,
    even though there is no . in your program.


    Actually, that explanation is distracting, and hilights the fact that
    your patch gives the only mention of $.

    Any chance that other file-handle special vars are affected ?
    does your patch magically report them too ?
    (Im not thinking of any example, sane or otherwize, just conjecture)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 26, '09 at 3:19p
activeMay 27, '09 at 2:17a
posts2
users2
websiteperl.org

2 users in discussion

Vincent Pit: 1 post Jim Cromie: 1 post

People

Translate

site design / logo © 2022 Grokbase