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)
[download]

$"=$,,$_=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
[download]

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

Update: Oops, this isn't the message you're talking about. Disregard. Try searching for no more than "subroutine entry". I think this error message is assembled.

Win32::API::Struct expects certain variables to be initialized where it doesn't really matter. Specifically, you must call ->align('auto') on a Win32::API::Struct instance after creating it. Also, you need to initialize all the fields of the struct. If you don't, passing this structure to an API function will cause numerous warnings by Win32::API::Struct::getPack as it tries to create a C version of the structure.

An example from my replies to 391557:

Win32::API::Struct->typedef(MEMORYSTATUS => qw{
   DWORD dwLength;
   DWORD MemLoad;
   DWORD TotalPhys;
   DWORD AvailPhys;
   DWORD TotalPage;
   DWORD AvailPage;
   DWORD TotalVirtual;
   DWORD AvailVirtual;
});
   
my $MEMORYSTATUS = Win32::API::Struct->new('MEMORYSTATUS');

# Avoid warning at Struct.pm line 214
$MEMORYSTATUS->align('auto');

# Avoid all other warnings in Struct.pm
$MEMORYSTATUS->{'dwLength'    } = 0;
$MEMORYSTATUS->{'MemLoad'     } = 0;
$MEMORYSTATUS->{'TotalPhys'   } = 0;
$MEMORYSTATUS->{'AvailPhys'   } = 0;
$MEMORYSTATUS->{'TotalPage'   } = 0;
$MEMORYSTATUS->{'AvailPage'   } = 0;
$MEMORYSTATUS->{'TotalVirtual'} = 0;
$MEMORYSTATUS->{'AvailVirtual'} = 0;
[download]