New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perlvar - recommend numeric comparisons for $] #17087
Comments
From @GrinnzThe $] variable is a numeric version and so numeric comparisons should be -Dan |
From @GrinnzPatch is attached. |
From @Grinnz0001-recommend-numeric-comparisons-for.patchFrom ca07388701b8a02eea0470e23ff9ad05488d0d3e Mon Sep 17 00:00:00 2001
From: Dan Book <grinnz@grinnz.com>
Date: Tue, 9 Jul 2019 01:36:32 -0400
Subject: [PATCH] recommend numeric comparisons for $]
---
pod/perlvar.pod | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/pod/perlvar.pod b/pod/perlvar.pod
index 1f9c08ce36..38111559fc 100644
--- a/pod/perlvar.pod
+++ b/pod/perlvar.pod
@@ -437,12 +437,11 @@ is the subversion / 1e6. For example, Perl v5.10.1 would be "5.010001".
This variable can be used to determine whether the Perl interpreter
executing a script is in the right range of versions:
- warn "No PerlIO!\n" if $] lt '5.008';
+ warn "No PerlIO!\n" if "$]" < 5.008;
-When comparing C<$]>, string comparison operators are B<highly
-recommended>. The inherent limitations of binary floating point
-representation can sometimes lead to incorrect comparisons for some
-numbers on some architectures.
+When comparing C<$]>, numeric comparison operators should be used, but the
+variable should be stringified first to avoid issues where its original
+numeric value is inaccurate.
See also the documentation of C<use VERSION> and C<require VERSION>
for a convenient way to fail if the running Perl interpreter is too old.
@@ -453,9 +452,10 @@ object, which allows more flexible string comparisons.
The main advantage of C<$]> over C<$^V> is that it works the same on any
version of Perl. The disadvantages are that it can't easily be compared
to versions in other formats (e.g. literal v-strings, "v1.2.3" or
-version objects) and numeric comparisons can occasionally fail; it's good
-for string literal version checks and bad for comparing to a variable
-that hasn't been sanity-checked.
+version objects) and numeric comparisons are subject to the binary
+floating point representation; it's good for numeric literal version
+checks and bad for comparing to a variable that hasn't been
+sanity-checked.
The C<$OLD_PERL_VERSION> form was added in Perl v5.20.0 for historical
reasons but its use is discouraged. (If your reason to use C<$]> is to
--
2.20.1
|
From @xdgThat's not a good idea. While it seems like $] is numeric, it's not: $ peekperl -wE 'Dump($])' Given that the data is string data, it should be compared Even older Perls have a string representation, so old and new comparisons $ peekperl -wle 'Dump($])' On Tue, Jul 9, 2019 at 1:40 AM Dan Book via RT <perlbug-followup@perl.org>
-- |
The RT System itself - Status changed from 'new' to 'open' |
From @GrinnzOn Sun, 14 Jul 2019 18:37:18 -0700, xdg@xdg.me wrote:
Yes, it is internally a string, but it is a numeric comparison and such should be recommended. This avoids confusion where '5.006' and '5.006000' are different in a lexicographic comparison. As long as it is first stringified the numeric comparison is consistent. -Dan |
From @xdgI suggest researching why the numeric representation was removed and Additionally, this part of the patch makes no sense to me:
In what way does creation of a PV representation change how NV comparison If you want to improve version comparison, marking $] "discouraged" in On Sun, Jul 14, 2019 at 10:35 PM Dan Book via RT <perlbug-followup@perl.org>
-- |
From @sisyphusOn Mon, 15 Jul 2019 04:04:16 -0700, xdg@xdg.me wrote:
David, you omitted the opening "+", which I've inserted above. +When comparing C<$]>, numeric comparison operators should be used.
Not so sure about that suggestion, however. Cheers, |
From @GrinnzOn Mon, 15 Jul 2019 04:04:16 -0700, xdg@xdg.me wrote:
I will be happy to do this when I have time, though I of course do not have access to such exotic architectures. In my opinion the likelihood of someone comparing $] incorrectly with lexicographical operators is higher than the likelihood they are using such an architecture. But that is a judgment for the porters to make. I'll also add that while I already thought this was the recommended approach, the impetus for this patch was an instance where the lexicographical comparison fails but the numeric comparison succeeds on some ancient version (5.00403?), but use of such is also very unlikely.
I do not think this will ever be a good idea, at least for a decade or two. |
From @khwilliamsonOn 7/15/19 5:03 AM, David Golden wrote:
The reason this topic has surfaced is that I've been working on One argument on #irc was that the same architecture is doing all the It would be good if someone has a concrete counterexample of how this is
|
Migrated from rt.perl.org#134273 (status was 'open')
Searchable as RT134273$
The text was updated successfully, but these errors were encountered: