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

Monks,

I have found a bug in perl... version 5.6.0. Yeah, don't laugh.

Seriously though, the problem is minor, and was fixed in 5.6.1. Here's a script that exposes the problem:

use strict; use Data::Dumper; print "$]\n", Dumper([qw[ \\d ]]), "\n";

On 5.6.0 and 5.6.1, respectively, one gets:

# with 5.6.0 5.006 $VAR1 = [ '\\\\d' ]; # 5.6.1 5.006001 $VAR1 = [ '\\d' ];

The perldelta says of this:

qw(a\\b) In Perl 5.6.0, qw(a\\b) produced a string with two backslashes instead of one, in a departure from the behavior in previous versions. The older behavior has been reinstated.

Sooooo.... on testers.cpan.org the module now has an ugly FAIL blemish against it (or will have when the web page gets around to indexing the latest results). And I hate it when that happens.

The first release had a number of failures because I had my skip counts messed up if Test::Deep was not installed. So I fixed that, but I don't know how to fix this.

I have two ways forward, hence my questions: How can I specify, as a prerequisite, that the version of perl used must be anything except 5.6.0? With MakeMaker? Or with Module::Build, as I suppose I should switch to that?

Otherwise, if I read the delta correctlyl, I can work around the bug simply by:

s/\\\\/\\/g if $] eq '5.006'

...in the appropriate place and it should work (with a probable WARNING in large letters in the README and/or man page). Is this Robust and an example of something that does The Right Thing, or just plain stupid? I'm not really fussed about supporting 5.6.0. I'm just somewhat selfishly interested in having my module pass its test suites as much as possible.

(The module is Regexp::Assemble, in case you were interested).


update: heh heh, I've just had an evil thought. I could always skip the tests and throw up a big warning at that point if the test was being run with 5.6.0...

- another intruder with the mooring of the heart of the Perl

Replies are listed 'Best First'.
Re: Working around a 5.6.0 bug
by gaal (Parson) on Dec 09, 2004 at 18:24 UTC
    Why the guilty doubts? The bug does exist, is in perl 5.6.0, and has been fixed in newer versions.

    This craving people have for perfect test results (and sometimes more absurdly, 100% coverage) is excessive. Tests are great for many reasons, but they are forever A TOOL.

    Do you expect your code to fail on 5.6.0? If not, you shouldn't have this test. Not "shouldn't have this test fail", but not have this test, period, because it isn't indicative or a real problem. If your code can fail on 5.6.0, either make 5.6.1 a prerequisite, or decide to fix the problem -- in the code, first -- knowingly bloating your code but happy in the knowledge that you know why you did it (and that tests helped you make an informed decision).

      Sounds like a reason to require 5.6.1. 5.6.0 is pretty old.
        So is 5.6.1 :-)
Re: Working around a 5.6.0 bug
by dragonchild (Archbishop) on Dec 09, 2004 at 18:12 UTC
    Tests get skipped if you're on the wrong OS ... I don't see a problem behind skipping if the Perl version is wrong. I'd put a warning in the Makefile.PL as well, too. That way, people don't even have to get to the tests.

    Another option is "use 5.6.1;" :-)

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: Working around a 5.6.0 bug
by mpeters (Chaplain) on Dec 09, 2004 at 18:44 UTC
    In Module::Build you would just:
    my $build = Module::Build->new( #whatever requires => { 'perl' => '5.6.1', } );
    I'm sure there's a way that's just as easy with MakeMaker
Re: Working around a 5.6.0 bug
by Animator (Hermit) on Dec 09, 2004 at 18:52 UTC
    Or you could overload the qw// operator (which is not something I would advice but it's a possibility (which is why I mentioned it))