in reply to Re^6: Weird behavior of int()
in thread Weird behavior of int()

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;

[download]
because passing NaN to the controller would let a non-integer value leak through to the code beyond.

Replies are listed 'Best First'.
Re^8: Weird behavior of int()
by syphilis (Archbishop) on May 24, 2024 at 04:41 UTC
    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));
}

    [download]
    However, in your case, assuming that $limit > ~0 >> 1, you could just do it as: 
    IV _to_IV(SV * in) {
  return SvIV(in);
}

    [download]
    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]

In Section Seekers of Perl Wisdom