Wolfgang J�hrling <[EMAIL PROTECTED]> 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
