[#1094] Re: [ruby-cvs] ruby, ruby/lib: * eval.c (ev_const_defined, ev_const_get), variable.c — Dave Thomas <dave@...>

> * eval.c (rb_mod_autoload, rb_mod_autoload_p): new method;

12 messages 2003/05/29
[#1095] Re: [ruby-cvs] ruby, ruby/lib: * eval.c (ev_const_defined, ev_const_get), variable.c — nobu.nokada@... 2003/05/29

Hi,

Isn't NUM2UINT broken for 64-bit?

From: "lyle@..." <lyle@...>
Date: 2003-05-29 17:32:25 UTC
List: ruby-core #1099
All,

I'm seeing a problem on a 64-bit DEC Unix box, and my initial analysis is
that NUM2UINT (and possibly others) are broken for this platform. Here,
sizeof(int) == 4 bytes and sizeof(long) == 8 bytes. So if you look at the
definitions in ruby.h, you get this definition for NUM2UINT:

    #define NUM2UINT(x) ((unsigned int) NUM2INT(x))

and the corresponding definition for NUM2INT is:

    #define NUM2INT(x) (FIXNUM_P(x) ? FIX2INT(x) : rb_num2int(x))

The problem with this is that if you pass in a Ruby Integer that is greater
than the maximum value for a *signed* integer, the conversion fails, since
both rb_fix2int() and rb_num2int() compare their inputs to INT_MAX. I am
specifically seeing this problem for the value (2**32 - 1), which is in
range for unsigned integers, but I suppose it will happen for any Integer
greater than INT_MAX.

Is this a bug, or am I missing something?

Thanks,

Lyle

In This Thread

Prev Next