http://www.perlmonks.org?node_id=415183


in reply to Source of warning message: "Use of uninitialized value in subroutine entry"

The fact that you're using XS explains a lot of this.

To understand what's going on here, you need to better understand what the warning message actually means.

The "Use of unitialized value" part is, as you surmised, referring to the usage of an undefined scalar as part of some operation. However, your assumption that 'in subroutine entry' means 'as part of the sub's arguments' is wrong. (If it did, then you'd get a warning every time you passed undef to a subroutine!) It actually means 'and the last Perl opcode that was run was the "entersub" opcode'. Similarly, the file/line number data you have came from the last "nextstate" opcode Perl processed.

Because XS code is plain C, and not Perl bytecode, Perl can't know to update its file/line number information, or its last-opcode information. I was able to reproduce your problem doing this:

# XS code SV* useofuninit(SV* arg) INIT: char *p; STRLEN plen; PPCODE: p = SvPVx(p, plen); XSRETURN_UNDEF; # Perl code my $foo; useofuninit(undef)
SvPVx() gets the string value from a scalar. In this case, it sees that the scalar is undef, and before upgrading it to an empty string scalar, it calls report_uninit(). report_uninit() checks the last opcode data and reports the warning to you as 'in subroutine entry'.
--Stevie-O
$"=$,,$_=q>|\p4<6 8p<M/_|<('=> .q>.<4-KI<l|2$<6%s!<qn#F<>;$, .=pack'N*',"@{[unpack'C*',$_] }"for split/</;$_=$,,y[A-Z a-z] {}cd;print lc

Replies are listed 'Best First'.
Re^2: Source of warning message: "Use of uninitialized value in subroutine entry"
by BrowserUk (Patriarch) on Dec 15, 2004 at 21:16 UTC

    Many thanks for the clear and cogent explaination.

    I don't actually do any XS, but I do use modules which do, and that would appear to be the source of the problem. I still remains somewhat mysterious that on all the occasions where this has come up, the code in question has worked fine and I have just ignored the warning.

    Slightly more troubling is the I am making a gut-feel association between the appearance and disappearance of the warning, with changes to the formatting of the source code, rather than the logic. But that's only a feeling have.

    I've encountered it enough time that my first instinct is to disable the warning and get on with what I am coding, rather than trying to debug the source of the problem itself.

    I'll know better what to be looking for the next time it comes up. Now, armed with better info, I'll try to be more dilligent next time.

    Again, my thanks for the education.


    Examine what is said, not who speaks.        The end of an era!
    "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
    "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon