Let's try that again; cpan.org's mailserver is dead in the water and I forgot to
delete the listserv from the cc: (so it didn't post to the newsgroup interface
either). This isn't exactly the same thing as I sent the first time because
I've thought of some other things (but I think Rafael is the only one who might
have received it)...

Jos I. Boumans wrote:
that a Very Large Number as a minimum version is said to be higher than
whatever version it finds in the installed version of a Module on the OS.
So if I could give you an "infinite" version object to test against, you would
be happy? :-)
The test in CPANPLUS will be fixed, i suggest you also add a guard for
too big numbers passed to qv().
There *is* a guard; it croak's as soon as the number overflows... ;-)
A few thoughts:

1) Wrap it in an eval
version.pm is primarily written in XS/C and the pure Perl version is only there
for compatibility. It is also in the v5.10.0 core as C code directly...
2) Ask the system what the biggest IV is and then compare it to
the input passed to qv().
Here's the rub. The code in question is actually parsing the string
representation passed in, one digit at a time (recall that this code began its
life in toke.c). There isn't any point where I *can* compare it to
PERL_INT_MAX, until it has already overflowed, when it is already too late.
I find it hard to believe that the only course of action is to let
the program abruptly end.
I can't think of a more logical response. Overflowing your numeric type is a
"very bad thing" and the only responsible course of action is to make that a
fatal error. The data is no longer reliable at that point.


Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2019 Grokbase