Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Interesting: a genuine Perl-bug

by sundialsvc4 (Abbot)
on Sep 22, 2010 at 13:04 UTC ( [id://861269]=perlquestion: print w/replies, xml ) Need Help??

sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:

Wow.   I just encountered my first bona-fide bug in Perl.   (“ v5.10.0 built for aix-64all”)

I encountered the following message and could not make it go away:

Bareword "state" not allowed while "strict subs" in use at alljobs.pl line 47. alljobs.pl had compilation errors.

But in the line cited by the message, state was obviously not a bareword:
$state = 1;

Finally, somewhat in desperation now, I enclosed the line with statements to suppress the error:

no strict 'subs';$state = 1; use strict 'subs';

And this time when I checked the syntax, I got a different message:

Unquoted string "state" may clash with future reserved word at alljobs +.pl line 63.

And, voilá!   A bareword occurrence of the variable state did exist...

state = 5;

... but on line 63, not 47.

Okay, sure... it’s a very small insect.   The syntax error that Perl had caught did, in fact, exist.   But it did not occur at the location cited in the message.   (The message seems to have cited the first line, other than the variable-declaration itself, where the offending variable was used.)

So... the take-away for all this is... “just be aware of it.”

Replies are listed 'Best First'.
Re: Interesting: a genuine Perl-bug
by JavaFan (Canon) on Sep 22, 2010 at 13:16 UTC
    It's a know fact that Perl sometimes does not report the offending line correctly, being off by 16 lines however is impressive. Can you check whether this still happens with 5.12.2 and/or blead? I've tried to recreate your problem, but anything I try of the form
    my $state = 1; state = 2;
    results in a syntax error in the second line. Can you create a small example which gives this off-by-a-lot error?
Re: Interesting: a genuine Perl-bug
by bobr (Monk) on Sep 22, 2010 at 14:13 UTC
    Could not it be something like this case? Long story short - it was problematic source filter with Switch module.

    -- Roman

Re: Interesting: a genuine Perl-bug
by sundialsvc4 (Abbot) on Sep 22, 2010 at 13:31 UTC

    Unfortunately, this is at $WORK, so I can’t easily try other versions.

    In my code, the error-message was reported on a line ... other than the my $state; declaration ... where the offending variable did appear, just not the place where (it did!) occur as a bareword.   Hence, the code looked more like this:

    my $state = 0; ... $state = 1; #<--- BAREWORD REPORTED HERE ... $state = 4; ... state = 5; #<--- BUT THE BAREWORD IS ACTUALLY HERE

    The message line-number was not simply “off by some random amount.”   The variable did indeed occur as a bareword, elsewhere in the program.   The message simply cited the wrong line.

      I can not repeat your problem on my system with 5.10.0. The message points to the correct line:
      $ cat foo.pl my $state = 0; print "state = $state\n"; $state = 1; print "state = $state\n"; $state = 4; print "state = $state\n"; state = 5; print "state = $state\n"; $ $ perl -Mstrict foo.pl Can't modify constant item in scalar assignment at foo.pl line 7, near + "5;" Bareword "state" not allowed while "strict subs" in use at foo.pl line + 7. Execution of foo.pl aborted due to compilation errors. $ $ perl -v This is perl, v5.10.0 built for x86_64-linux Copyright 1987-2007, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge. $

      I also tried Perl versions 5.8.8 and 5.12.0.

      That's an interesting theory. But, as you found, the effect is quite unfortunate for the one trying to fix the error. I would personally love to see an example that can reproduce the problem. And such would make it more likely that the bug gets fixed. Thanks.

      - tye        

Re: Interesting: a genuine Perl-bug
by sundialsvc4 (Abbot) on Sep 22, 2010 at 15:06 UTC

    Okay, as it happens, I can show you the whole code.   This code has the error fixed.

    As I was fiddling with it, preparing it to copy here ... I couldn’t reproduce the error anymore.   This time, when I fiddled with the line, removing the "$", I got this message that I have not seen before:
    Can't modify constant item in scalar assignment at alljobs_file.pl line 67, near "4;"

    I have no idea why Perl would see it as “a constant item.”   (There is probably a clue lurking here, but I do not know what it would be.)

    Very strange.   So, the behavior that I am seeing is now inconsistent.   (And yes, it is running against a “local Perl.”)   Anyhow, the code is here:

    Don’t go looking for TWS::Parser in CPAN, because it doesn’t exist.   It is a parser that I am right now working-on to process Tivoli Workload Scheduler (e-e-e-e-e-e-yuck!) schedule and job files.   (And, by the way, it works.   For our very old version of TWS, anyway.   Anybody out there want such a thing?)

    I am not inclined to say that this issue is “high priority” or anything.   It is not.   Rather, I wanted to document the behavior because it caught me by surprise and wasted me some time.   There is, as you can see, no switch demagoguery or other such nonsense going on here:   it’s just straight Perl.

Re: Interesting: a genuine Perl-bug
by sundialsvc4 (Abbot) on Sep 22, 2010 at 19:21 UTC

    (Blink...)

    I just encountered a comment that is talking about “the state feature of Perl 5.10.”

    I know nothing about this feature (yet...), but could it be that this has something to do with what I am seeing here?

    (I’m not annoyed, nor show-stopped ... I’m curious now!)

      Hi sundialsvc4,

      It's a very cool feature of 5.10 which mimics the static variable of C.  State variables don't lose their data, even when they go out of scope, so you can use them for cases where you want data to persist, without having to use globals.

      For example, to perform initialization only once the first time a subroutine is called, you could do this:

      #!/usr/bin/perl -w use feature qw{ state }; use strict; use warnings; for (1..5) { some_sub(); } sub some_sub { (state $b_initialized++) or initialize(); print "Now doing the main work of some_sub() ...\n"; } sub initialize { print "Initializing....\n"; # ... etc ... } __END__ === Output === Initializing.... Now doing the main work of some_sub() ... Now doing the main work of some_sub() ... Now doing the main work of some_sub() ... Now doing the main work of some_sub() ... Now doing the main work of some_sub() ...

      Or to define a subroutine which returns a unique integer each time it's called:

      #!/usr/bin/perl -w use feature qw{ state }; use strict; use warnings; for (1..5) { printf "Got the value %d\n", unique_integer(); } sub unique_integer { return ++(state $ncalls); } __END__ === Output === Got the value 1 Got the value 2 Got the value 3 Got the value 4 Got the value 5

      s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/
      , but could it be that this has something to do with what I am seeing here?

      No, absolutely not.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://861269]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (3)
As of 2024-04-25 22:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found