Skip to content

Conversation

@sinisterchipmunk
Copy link
Contributor

This pull request was split from #14 as requested by @nobu . It depends on #25 because that pull request makes it possible to access the underlying memory of a struct, which is required in order for this pull request to work properly.

When a member of a struct is an array, CStructEntity would return a temporary array containing those values. Assignment to that array was a no-op, which led to confusing behavior because an assignment to the array would be "ignored". I fixed this so that assignment to the returned array correctly updates the member within the struct.

For example:

a = struct(['int i[5]']).malloc
a.i[2] = 1 # previously, this would do nothing
a.i[2] #=> 1


def []=(index, value)
if index < 0 || index >= size
raise RangeError, 'index %d outside of array bounds 0...%d' % [index, size]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe IndexError?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, I changed this.

raise RangeError, 'index %d outside of array bounds 0...%d' % [index, size]
end

to_ptr[index * @align, @size] = [value].pack(@pack_format)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why @align, shouldn't be @size?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this was wrong. I fixed the error, but I was unable to make it fail in a test case.

The test did not fail because, on my system, @align == @size for all primitive types. Therefore the result of using @align yields a correct value on my system, but could fail on other architectures. I modified the test case to attempt to write at several array indices, and then check that the underlying memory can be correctly unpacked. I think the modified test case covers the issue better than the original, even though I did not experience a failure, so I committed it.

@nobu nobu merged commit 2408369 into ruby:master Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants