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

I checked with B::Deparse and B::Concise and the variable name is clearly visible i.e not optimized away:

> perl -MO=Deparse,-q
use warnings;
my (%a, %b, $c);
my $x = "$a{'foo'} $b{'bar'} $c"
__END__
use warnings;
my(%a, %b, $c);
my $x = $a{'foo'} . ' ' . $b{'bar'} . ' ' . $c;
- syntax OK

[download]

-q reveals the mentioned optimization of string-interpolations, but the variable name is not affected.

lanx@nc10-ubuntu:~$ perl -w -MO=Concise
my (%a,%b,$c);
my $x = "$a{'foo'} $b{'bar'} $c";
o  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -:1) v:{ ->3
7     <@> list vKPM/128 ->8
3        <0> pushmark vM/128 ->4
4        <0> padhv[%a:1,3] vM/LVINTRO ->5
5        <0> padhv[%b:1,3] vM/LVINTRO ->6
6        <0> padsv[$c:1,3] vM/LVINTRO ->7
8     <;> nextstate(main 2 -:2) v:{ ->9
n     <2> sassign vKS/2 ->o
-        <1> ex-stringify sK/1 ->m
-           <0> ex-pushmark s ->9
l           <2> concat[t8] sKS/2 ->m
j              <2> concat[t7] sKS/2 ->k
h                 <2> concat[t6] sKS/2 ->i
d                    <2> concat[t5] sK/2 ->e
b                       <2> helem sK/2 ->c
9                          <0> padhv[%a:1,3] sR ->a           <-------
a                          <$> const[PV "foo"] s ->b
c                       <$> const[PV " "] s ->d
g                    <2> helem sK/2 ->h
e                       <0> padhv[%b:1,3] sR ->f              <-------
f                       <$> const[PV "bar"] s ->g
i                 <$> const[PV " "] s ->j
k              <0> padsv[$c:1,3] s ->l                        <-------
m        <0> padsv[$x:2,3] sRM*/LVINTRO ->n
- syntax OK

[download]

I thought this is only a negligible bug, such that after fixing $a{foo} the following $b{bar} would be visible, but that's unfortunately not the case:

>  perl -w 
my (%a, %b, $c);  
$a{foo}="FIXED";
my $x = "$a{'foo'} $b{'bar'} $c";
__END__
Use of uninitialized value in concatenation (.) or string at - line 3.
Use of uninitialized value $c in concatenation (.) or string at - line
+ 3.

[download]

Cheers Rolf

( addicted to the Perl Programming Language)

Replies are listed 'Best First'.
Re^3: Variable name missing in warning (source)
by tye (Sage) on Apr 03, 2014 at 06:24 UTC

    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        

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

In Section Seekers of Perl Wisdom