-
Notifications
You must be signed in to change notification settings - Fork 1.8k
test writes to direct byte buffers #229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
77fbdc3 to
49d5be0
Compare
|
Looks good to me - thanks for doing this. |
|
Why are there no long tests? |
|
Long tests? |
|
Too brief :) What I was trying to say, the new test tests for all basic datatypes except long: Is there a reason? |
|
Hi Chris! Well, the immediate reason is that this test does all the same checks as the non-direct byte buffer test. However, you have a point that writing longs ought to be tested. I was going to suggest as an excuse for this omission that these tests exercise cases where a fragment of the standard transfer unit is transferred i.e. that they test disassembly and reassembly of elements that make up such units, both at aligned and unaligned offsets. However, i) that doesn't apply when transferring doubles and ii) I am not sure there is any reason to omit testing that a full unit is transferred correctly both at aligned and unaligned offsets. So, yes, there is no good reason and, indeed, both tests are not actually as comprehensive as they need to be(also, in related news, the internet is broken! ;-) Perhaps this could be fixed with a follow-up commit? |
|
Unless there's an urgency for this PR, I'd prefer the extra tests to be added here to reduce the integration overhead on my side... pretty please... ;-) |
|
ok, I updated both byte buffer tests to check reads and writes of longs :-) |
|
Cool, thanks. Can you fix the internet too? |
As promised here is a unit test to check writes to direct byte buffers, It passes on x86 and AArch64 with the latest head.
n.b. I reverted the AArch64 address lowering code to revert the fix that updated usages one by one and, as expected, the unaligned int writes failed because the second byte of the int was being written at offset 1 rather than offset 2. So, this test would have caught the error in the original commit.