Skip to content
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

clarify requirements of byte_{offset,add,sub} for zero-sized referents #133576

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jswrenn
Copy link
Member

@jswrenn jswrenn commented Nov 28, 2024

The safety documentation on core::ptr presents this rule:

For operations of size zero, every pointer is valid, including the null pointer.

However, due to the implementation details of byte_{offset,add,sub}, which involve intermediate operations on non-zero-sized referents, this rule does not apply to these methods.

This commit clarifies extends the over-arching rule with an "unless otherwise noted" caveat, and clarifies the documentation of byte_{offset,add,sub} to note that the only valid count for zero-sized referents is presently 0 (though I wonder if this requirement might be relaxed).

cc @rust-lang/opsem

The safety documentation on `core::ptr` presents this rule:

> For operations of size zero, every pointer is valid, including the null pointer.

However, due to the implementation details of `byte_{offset,add,sub}`,
which involve operations on non-zero-sized referents, this rule does
not apply to these methods.

This commit clarifies extends the over-arching rule with an "unless
otherwise noted" caveat, and clarifies the documentation of
`byte_{offset,add,sub}` to note that the only valid `count` for
zero-sized referents is presently `0`.
@rustbot
Copy link
Collaborator

rustbot commented Nov 28, 2024

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 28, 2024
@saethlin
Copy link
Member

though I wonder if this requirement might be relaxed

I don't think it should be, I think of byte_ operations as doing arithmetic on the address while ignoring the pointee type. The whole point is ignoring the pointee type.

So I'm not sure what other behavior you would want for these methods on ZST pointees. Making them do nothing would be a breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants