Perl version comparison fails #15277
This is a bug report for perl from firstname.lastname@example.org,
The following oneliner fails:
$ perl5.22.2-RC1 -e '$ok = $] == 5 + (22/1000) + (2/1000000); !$ok and print "not "; print "ok 1\n"'
I observe this on this freebsd 9.2 system and another linux system (debian/wheezy, also perl 5.22.2-RC1).
What's expected is something like this:
$ perl5.22.1 -e '$ok = $] == 5 + (22/1000) + (1/1000000); !$ok and print "not "; print "ok 1\n"'
I noticed this problem because of failures in Acme-No-0.03 (which is creating
Looking at http://matrix.cpantesters.org/?dist=Acme-No%200.03 it seems that
$ perl5.14.2 -e '$ok = $] == 5 + (14/1000) + (2/1000000); !$ok and print "not "; print "ok 1\n"'
Maybe a floating point inaccuracy problem?
Site configuration information for perl 5.22.2:
Configured by eserte at Tue Apr 12 07:39:08 CEST 2016.
Summary of my perl5 (revision 5 version 22 subversion 2) configuration:
Locally applied patches:
@INC for perl 5.22.2:
Environment for perl 5.22.2:
On Sat, Apr 16, 2016 at 10:12 PM, email@example.com <firstname.lastname@example.org
Floating point numbers are inherently inaccurate. Using eq instead of ==
Dana Sub 16. Tra 2016, 13:42:13, LeonT reče:
OK, I see now that this problem is already mentioned in $]'s entry in perlvar.pod.
Not a bug; your computation of the comparand is faulty.
$ perl -lwe 'printf "%.70f\n"x2, 5.022002, 5+22e-3+2e-6'
Like most of our version numbers, the numerical value 5.022002 cannot
Nowadays $]'s numerical value is determined by correctly rounding the
For a numeric comparison that can be expected to match on all modern
$] == sprintf("%d.%03d%03d", 5, 22, 2)
To have the numeric comparison work on older perls too, force
"$]" == sprintf("%d.%03d%03d", 5, 22, 2)
Migrated from rt.perl.org#127909 (status was 'rejected')
Searchable as RT127909$
The text was updated successfully, but these errors were encountered: