3 ms·
That seems like a slightly dubious choice to me, since unsigned long isn't guaranteed to be as long as a pointer; for example, under Microsoft's 64-bit compiler
by archangel_one 15y ago
That seems like a slightly dubious choice to me, since unsigned long isn't guaranteed to be as long as a pointer; for example, under Microsoft's 64-bit compiler it's still only 4 bytes, but pointers are obviously 8. Possibly there is some extra preprocessor cleverness to deal with it, or maybe they don't expect it to work under that compiler?
- jof 15y agoIsn't this what C99's uintptr_t type tries to address?
- archangel_one 15y agoYes, exactly. I'm just a little curious since, without knowing anything about the code at all, unsigned long doesn't seem like a great choice. I'm sure the Ruby devs would know this though so I expect there must be some reason for it.
- bhousel 15y agoHere's the code: https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#L66 https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#... It looks like uintptr_t support is there, just disabled for now.
- archangel_one 15y agoThanks - the fallback to long long explains it for me.
- ben0x539 15y agoYeah, there's preprocessor cleverness. It will choose either of unsigned, unsigned long or unsigned long long. There's a "#if defind HAVE_UINTPTR_T && 0" section, I'm curious why they're effectively disabling that.