in reply to Re^2: Variable name missing in warning
in thread Variable name missing in warning

Then why don't you (anybody in this thread) go read (and understand) the near-400-line subroutine of C code that tries to find variable names for undef warnings?

See S_find_uninit_var in sv.c.

The docs didn't say that sometimes variable names are optimized away (the mention of optimization was about the reported operation). The docs pretty clearly hint (to me, anyway) that finding the variable name isn't close to a trivial task and is known to fail somewhat often for reasons too complicated to usefully summarize in those docs.

- tye        

  • Comment on Re^3: Variable name missing in warning (source)

Replies are listed 'Best First'.
Re^4: Variable name missing in warning (source)
by LanX (Saint) on Apr 03, 2014 at 10:02 UTC
    Is this a rhetoric question or do you really want to discuss why I don't do it?

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

    14857             sv = find_uninit_var(o, uninit_sv, 1);

    But I am not a C programmer and far from understanding Perl guts.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

[reply]
[d/l]
      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.

      - tye        

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

[reply]

In Section Seekers of Perl Wisdom