I guess the unspoken implied behavior of a function named "int()" can be interpreted more ways than I expected. When I use "int()" in perl, what I actually wanted was C's cast-to-int or JavaScript's parseInt(), followed by making assumptions that I have an integer safe for any integer purposes.
Having learned about these edge cases, now I need to go back through all the controllers I've written and fix:
my $count= int($c->request->params->{count});
$c->detach(HTTP => 422, ["Invalid count"])
if $count < 0 || $count > $limit;
because passing NaN to the controller would let a non-integer value leak through to the code beyond.
| [reply]
[d/l] |
When I use "int()" in perl, what I actually wanted was C's cast-to-int or JavaScript's parseInt()
I don't know of any perl function that will do that.
I'd do it as an XSub:
SV * _to_IV(SV * in) {
if(SvNV(in) < 0) return newSViv(SvIV(in));
return newSVuv(SvUV(in));
}
However, in your case, assuming that $limit > ~0 >> 1, you could just do it as:
IV _to_IV(SV * in) {
return SvIV(in);
}
which (if I'm thinking correctly) would still reject arguments greater than ~0 >> 1 because $count is negative.
Of course, you might prefer to just check that the arg is not a NaN, if you trust the NaN != NaN test or POSIX::isnan or somesuch.
Cheers,
Rob
| [reply]
[d/l]
[select] |