Issue #22285 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22285: FIX2INT loses consistency due to sizeof(int) https://bugs.ruby-lang.org/issues/22285 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In include/ruby/internal/arithmetic/int.h, FIX2INT is resolved to rb_fix2int or RB_FIX2LONG. ``` #define FIX2INT RB_FIX2INT /**< @old{RB_FIX2INT} */ /** * Converts a Fixnum into C's `int`. * * @param[in] x Some Fixnum. * @pre Must not pass anything other than a Fixnum. * @return The passed value converted into C's `int`. */ static inline int RB_FIX2INT(VALUE x) { /* “FIX2INT raises a `TypeError` if passed `nil`,” says rubyspec. Not sure if * that is the intended behavior, but just preserving backward compatibility. */ #if 0 RBIMPL_ASSERT_OR_ASSUME(RB_FIXNUM_P(x)); #endif long ret; if /* constexpr */ (sizeof(int) < sizeof(long)) { ret = rb_fix2int(x); } else { ret = RB_FIX2LONG(x); } return RBIMPL_CAST((int)ret); } ``` RB_FIX2LONG takes a fast path using shift operations, whereas rb_fix2int performs a more complex process by calling rb_num2long based on the result of the FIXNUM_P check. This goes beyond the scope of rdoc and doc/extensions. Is it intended behavior for FIX2INT to call to_int? Since the FIXNUM_P guard has become an idiom, this seems like unnecessary behavior. Note that there is a possibility that an implementer could unintentionally create code that breaks under Windows and probably 32-bit platforms, (see Bug #22284) -- https://bugs.ruby-lang.org/