Repository navigation
Honor pointer offsets in getByteBuffer views - #50
Draft
RicheyWorks wants to merge 1 commit into
Draft
RicheyWorks wants to merge 1 commit into
RicheyWorks wants to merge 1 commit into
Conversation
Owner
|
Great. 22 pull requests in a few hours. To be clear: I'm not going to review these. If someone wants me to review and integrate them, and create a new release, send me a mail. My rate per hour is about one tenth of the profit that NVIDIA makes per second. Pretty cheap, right? |
Author
|
I am disabled and only make 450 bucks a month. I understand your bandwidth is low and im sure you already have plenty of money in respect to me; have a nice life |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pointer.getByteBufferignores the pointer's stored byte offset. For example,Pointer.to(new byte[] {0, 1, 2, 3}).withByteOffset(2).getByteBuffer()returns all four bytes starting at zero, rather than the two bytes beginning at the shifted pointer. The ranged overload similarly reads from the unshifted base and may accept ranges that extend past the shifted pointer's remaining memory.Honor the stored offset in both overloads, check range arithmetic for overflow, and document pointer-relative behavior. Keep zero-offset behavior, shared backing memory, native byte order and null results for unsupported pointers. Explicitly retain rejection of negative relative offsets and sizes.
Add 12 no-CUDA regression cases covering shifted and composed offsets, direct sliced memory, shared writes, caller buffer state, end boundaries, invalid ranges, arithmetic overflow, unsupported pointers and unchanged zero-offset behavior. Eight cases fail on unchanged upstream; all 12 pass after the fix.
Validation:
mvn -B -ntp -o -f JCudaJava/pom.xml -Dmaven.repo.local=<task-local-cache> -Dtest=PointerByteBufferOffsetTest test: BUILD SUCCESS, 12 tests, zero failures/errors/skips, declared JUnit 4.13.1.jcuda-parentPOM installed into an isolated cache with Java 8 source/target, as for Preserve direct buffer marks in Pointer.toBuffer #49. No POM adjustment is included in this PR.This intentionally changes buffer views of offset pointers to match their pointer-relative meaning. Callers that relied on the previous ignored-offset behavior will see different data and buffer sizes.