So, it is that FIXNUM of the 64-bits ruby is a 32-bits data?
But my friend try these code on linux platform and all got true(it means FIXNUM is 64bits)
Then I opened ruby/ruby.h and found this:
#define RUBY_FIXNUM_MAX (LONG_MAX>>1)
The LONG_MAX of my compiler(msvc140, vs2017) is 2147483647, and the ruby which is installed by ruby-installer also have the same problem.
So, it is that FIXNUM of the 64-bits ruby is a 32-bits data?
Yes, we are using long for fixnums, and Windows is the so-called IL32LLP64 platform.
To "fix" this, or relax this limitation, we have to replace tons of long in the source code.
I'm using vs2017 and embed ruby interpreter in my game engine. In certain situation I need to use Fixnum to pass values of pointers(64-bits pointers). So ruby will use big integer to pass the pointer's values, what may cause unsatisfying performance on runtime speed.
To "fix" this, or relax this limitation, we have to replace tons of long in the source code.
Oh...I tried just now. The codes uses so large amount of '#define' to alias types' names, it makes the work more difficult.....
what I only want to say is 'why didn't use typedef?...' I found that Matz once said 'IL32LLP64 platform is not hackneyed' :(
This is indeed very surprising that on a platform with 64-bit pointers, Fixnum are still only 30 bits.
+1 to making this more intuitive.
It creates a lot of weird edge cases in ruby/spec.
There are also places in the code where VALUE is used as a synonym of unsigned long (e.g.: rb_uint2inum(VALUE)) but those should just be replaced by "unsigned long".
This issue is still present in the master branch. However, the range of T_FIXNUM is an implementation detail, especially since Integer unification in Ruby 2.4, so I do not think this is a bug. I think we wouldn't be opposed to increasing the range of Fixnum on 64-bit Windows, but I consider that a feature request.