[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ruby status



Wolfgang Jährling <wolfgang@pro-linux.de> writes:

> - The errno constants are wrong. For example, Errno::EBUSY::Errno
>   does not give us EBUSY (0x40000010), but 0xC0000010. This has
>   probably to do with the fact that Ruby converts the error codes
>   to Fixnums and the Ruby Fixnum type is a 31-Bit integer. The
>   Fixnum type is optimized for performance through some dirty hack:
...
>   It uses the least significant bit (bit 0) of a VALUE to
>   indicate that it is a Fixnum and stores the number in the bits
>   1-31, that's the reason why Fixnum is a 31-Bit integer.

This is of course an old and quite standard hack. The terminology
"fixnum" comes from the LISP world, I think (although I can't find the
word "FIXNUM" in the old LISP-1.5 manual (LISP-1.5 was long before
my time, but I do have the manual)).

Emacs uses the same trick, but uses a few more tag bits, giving
fixnums a size of 28 bits on a 32-bit machine. Does emacs give access
to to numerical errno values? Then it would have the same problem. I
remember that access to time_t values is somewhat complicated, as
these values are (or were, it's some years since I read those parts of
the manual) split up as a cons cell with two fixnums, before any lisp
code sees them.

>   Could this be some signed/unsigned
>   problem? At least ruby -e 'puts Errno::EBUSY::Errno' prints the
>   number -1073741808. Perhaps replacing INT2FIX() with INT2NUM()
>   where   Ruby converts the errno constants to VALUEs would solve
>   this problem, I did not test this yet.

Is NUM a bignum type? If not, I don't think that will help. The sign
extension doesn't take place when the errno values are converted to
ruby values, it happens when numbers are extracted from the 31-bit
value field into C variables.

What is the largest errno value that the Hurd uses? Does it fit in 31
bits?

/Niels



Reply to: