3 ms·

Extremely interesting. But I cannot quite understand why RSTRING_EMBED_LEN_MAX is calculated that way. VALUE seems to be unsigned int defined via "typedef uint

Extremely interesting. But I cannot quite understand why RSTRING_EMBED_LEN_MAX is calculated that way. VALUE seems to be unsigned int defined via "typedef uintptr_t VALUE;" and "typedef unsigned __int64 uintptr_t;" But why is it calculated like that I don't get. Anyone can explain?

Dylan16807 13y ago
Good question. In a really roundabout way it manages to be the same size as the alternative struct. Edit: I missed that part of that was another union, removed what I said about it being off on 32 bit. I still don't understand why they go so roundabout by dividing by one and casting to int...
- Sharlin 13y ago
  Actually in C and C++, longs are 32 bit on most 32-bit platforms. If you need a 64-bit integer type, you need either "long long" or some implementation-specific equivalent.
  - Dylan16807 13y ago
    I know that, I misread it as using two longs plus two pointers, fixed it now.
Sharlin 13y ago
The small string buffer should be the same size as the "heap" struct so as not to waste memory -- remember, they shared the memory as they're members of a union. The heap struct contains three members which, taking into accoult alignment restrictions, usually add up to three times the machine word size (which is basically what sizeof(uintptr_t) is). The "-1" is because C strings are null-terminated, so the maximum length is one less than the size of the buffer. What I don't know is why they don't simply use sizeof(heap) as the buffer size.
- grosbisou 13y ago
  Ah that was obvious. Thanks, very clear answer.
al2o3cr 13y ago
It's using the storage in an RString struct that isn't otherwise occupied by the RBasic info: https://github.com/ruby/ruby/blob/8f77cfb308061ff49de0a47e82816c8dafa27963/include/ruby/ruby.h#L819 https://github.com/ruby/ruby/blob/8f77cfb308061ff49de0a47e82... Note the `as` union. The `heap` version has three VALUE-sized entries, so RSTRING_EMBED_LEN_MAX is calculated accordingly, with the -1 to account for the null terminator.

Dylan16807 13y ago

Good question. In a really roundabout way it manages to be the same size as the alternative struct. Edit: I missed that part of that was another union, removed what I said about it being off on 32 bit. I still don't understand why they go so roundabout by dividing by one and casting to int...

Sharlin 13y ago
Actually in C and C++, longs are 32 bit on most 32-bit platforms. If you need a 64-bit integer type, you need either "long long" or some implementation-specific equivalent.
- Dylan16807 13y ago
  I know that, I misread it as using two longs plus two pointers, fixed it now.

Sharlin 13y ago

The small string buffer should be the same size as the "heap" struct so as not to waste memory -- remember, they shared the memory as they're members of a union. The heap struct contains three members which, taking into accoult alignment restrictions, usually add up to three times the machine word size (which is basically what sizeof(uintptr_t) is). The "-1" is because C strings are null-terminated, so the maximum length is one less than the size of the buffer. What I don't know is why they don't simply use sizeof(heap) as the buffer size.

grosbisou 13y ago
Ah that was obvious. Thanks, very clear answer.

al2o3cr 13y ago

It's using the storage in an RString struct that isn't otherwise occupied by the RBasic info: https://github.com/ruby/ruby/blob/8f77cfb308061ff49de0a47e82816c8dafa27963/include/ruby/ruby.h#L819 https://github.com/ruby/ruby/blob/8f77cfb308061ff49de0a47e82... Note the `as` union. The `heap` version has three VALUE-sized entries, so RSTRING_EMBED_LEN_MAX is calculated accordingly, with the -1 to account for the null terminator.