1

I make use of Integer( param ) in Ruby and NUM2INT( param ) in native extensions as a way of accepting any param that could be cast to an Integer in my public interfaces.

Recently I came across a difference in behaviour between Ruby 1.8 and 1.9 where 1.9 raises an error, but 1.8 makes an unwanted coercion from Symbol to Fixnum (or to an equivalent int in C):

In 1.9.3, behaviour I want:

1.9.3-p327 :001 > Integer( :foo )
TypeError: can't convert Symbol into Integer

In 1.8.7, behaviour I don't want:

1.8.7 :001 > Integer( :foo )
 => 15081

This came out as I asserted TypeError in a test when sending in a Symbol param instead of Integer, and I got some Travis fails as a result. For now, I've stopped using Symbols as examples of bad parameters in my test. But could/should I do more for 1.8.7 compatibility?

Neil Slater
  • 26,512
  • 6
  • 76
  • 94
  • Why would you do this? Isn't `.to_i` good enough? – tadman Jul 16 '13 at 16:18
  • @tadman: `.to_i` is not available in native extensions (at least not without calling back out to Ruby). `Integer()` and `NUM2INT()` appear to be equivalents. But perhaps the best answer could be to try `.to_i` on the params instead? It would make some of the C code a bit more complex, but definitely possible – Neil Slater Jul 16 '13 at 16:20
  • 1
    You can call methods on Ruby objects from within the C environment, and it's probably the best way to go about recasting arguments. It's also possible to have a thin Ruby layer around your C extensions that converts the parameters into the appropriate format before passing them through to your C layer. – tadman Jul 16 '13 at 16:22

0 Answers0