Skip to content

Request: add, sub, and offset for NonNull #90549

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

Closed
Lokathor opened this issue Nov 3, 2021 · 5 comments
Closed

Request: add, sub, and offset for NonNull #90549

Lokathor opened this issue Nov 3, 2021 · 5 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@Lokathor
Copy link
Contributor

Lokathor commented Nov 3, 2021

Currently, offsetting a non-null pointer is quite cumbersome. It would be better if these pointer methods were provided directly on the NonNull type instead of having to get the inner pointer, do the change, and then call NonNull::new_unchecked on that output.

@fee1-dead
Copy link
Member

offsetting/subtracting a NonNull pointer needs to return an Option<NonNull>, since the offset could make the pointer null again. e.g. 0x1.offset(-1) should return None.

I think add is fine, though.

@hkratz
Copy link
Contributor

hkratz commented Nov 4, 2021

add is not fine either:

let ptr = usize::MAX as *const u8;
unsafe {
    assert_eq!(ptr.add(1), core::ptr::null());
}
Edit: Nevermind that is UB even for normal pointers. The implementation should probably still assert in `NonNull.add()` that the result is not null.

@Lokathor
Copy link
Contributor Author

Lokathor commented Nov 4, 2021

The standard rules of add/sub/offset would still apply, specifically that the calculation does not go outside of an allocation or one byte past the end of an allocation, and also that the calculation does not wrap within the address space.

So it would already be UB to sub or offset to 0, separate from the non-null rule. Similarly it would already be UB to add or offset past the end of the address space, so wrapping around to 0 is also not a concern.

@Dylan-DPC Dylan-DPC added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Feb 18, 2023
@antoyo
Copy link
Contributor

antoyo commented Jun 9, 2023

Seems to be a duplicate of #72429.

@Dylan-DPC
Copy link
Member

Closing this as duplicate of #72429

@Dylan-DPC Dylan-DPC closed this as not planned Won't fix, can't repro, duplicate, stale Dec 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

5 participants