Use rb_ary_entry instead of RARRAY_PTR #877
Conversation
For MRI, this doesn't make a difference, but on Rubinius this prevents having to setup a backing store for copying over the internal array pointers. This was the only case where RARRAY_PTR was used, other places already use rb_ary_entry, so it should be a good change for consistency as well.
|
Any way to get this merged? Or is there anything that would hold this back? |
|
@dbussink Getting a segfault on rbx-18mode. I'm happy to merge this once this runs green but @flavorjones might want to wait until after 1.6.0 is released |
|
I don't see how this could be related to the Rubinius segfault, since I actually changed this because it works better for Rubinius (and ran the tests locally). I guess they were due to some other issue that existed when I sent this pull request that has been fixed in the mean while. Also this change is really minor, so don't really see how it would affect a release, but it's not my decision of course :). |
|
@dbussink I agree on both counts. I'll run this against travis again so it's running green, I'm happy to merge before the release :) will catch up with this later. Thanks |
Use rb_ary_entry instead of RARRAY_PTR
For MRI, this doesn't make a difference, but on Rubinius this prevents
having to setup a backing store for copying over the internal array
pointers. This was the only case where RARRAY_PTR was used, other places
already use rb_ary_entry, so it should be a good change for consistency
as well.