Is this a rhetoric question or do you really want to discuss why I don't do it?

It is both rhetorical (as in simply an encouragement for people to ask that question of themselves) and not (yes, I'm interested in what reasons people have for not looking at the source code).

But I am not a C programmer

You don't have to be a C programmer to be able to read a lot of C code. Most of it is very similar to Perl code and you are a Perl programmer. And C is an almost minimalist language (sometimes compared to "assembly" because of how minimal it is, though it is much easier to understand than any assembly language I've studied). So the things you'd need to learn about C that aren't almost identical to things you already know in Perl are very few (and some of those you just won't run into).

and far from understanding Perl guts.

There are tons of things I don't know about Perl guts. But the things I do know about Perl guts I mostly learned by looking at code that makes up the Perl guts. So I encourage you to look at Perl code if you are going to talk about obscure implementation details and speculate about what is or isn't a bug.

You are already looking at B::Concise output so you are already looking at the type of Perl guts that is being dealt with in the C code I pointed at.

FWIW my best guess is that the 1 causes the recursive search to only match scalar values.

I don't think so. The comments:

If match is true, only return a name if its value matches uninit_sv. So roughly speaking, if a unary operator (such as OP_COS) generates a warning, then following the direct child of the op may yield an OP_PADSV or OP_GV that gives the name of the undefined variable. On the other hand, with OP_ADD there are two branches to follow, so we only print the variable name if we get an exact match.

indicate (to me, anyway) that specifying '1' for 'match' just means that you aren't dealing with a unary operator.

> yes, I'm interested in what reasons people have for not looking at the source code

Well my contribution was to highlight that it is not impossible to find the undef variable (not optimized away)

I had no idea where to find the source code, and it's actually full of macros which are very cryptic for me.

> You are already looking at B::Concise output ...

Thats the level (with the help of B::Deparse) I'm hoping to understand soon.

update

FWIW I don't consider this an important problem, so at least it's good to have it documented now.

Cheers Rolf

( addicted to the Perl Programming Language)