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:
- References:
- Ruby status
- From: Wolfgang Jährling <wolfgang@pro-linux.de>