Skip to content

document preservation of padding in operations on pointers #695

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.

Sign up for GitHub

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

Open
tshepang wants to merge 5 commits into
base: main
Choose a base branch
from
+18 −0
Open

document preservation of padding in operations on pointers #695

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8367ad0
document preservation of padding in operations on pointers
tshepang Apr 16, 2026
00eb3ee
be more consistent with other ub paragraphs
tshepang Apr 21, 2026
56265dd
add some links
tshepang Apr 21, 2026
e1cade0
add ub marker
tshepang Apr 21, 2026
d22f218
use the full term
tshepang Apr 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions src/changelog.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,13 @@ Language changes in Rust 1.95.0
- The target is outside the scope of the FLS.

- `const-eval: be more consistent in the behavior of padding during typed copies <https://github.com/rust-lang/rust/pull/148967>`_

New paragraphs:

- :p:`fls_LmPbrh0Cba8g`
- :p:`fls_nwgIMLkvD2Ol`
- :p:`fls_hOIImCr1c6IF`

- `Const blocks are no longer evaluated to determine if expressions involving fallible operations can implicitly be constant-promoted <https://github.com/rust-lang/rust/pull/150557>`_
- `Make operational semantics of pattern matching independent of crate and module <https://github.com/rust-lang/rust/pull/150681>`_

Expand Down
5 changes: 5 additions & 0 deletions src/expressions.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,6 +341,11 @@ control reaches the invocation of :t:`macro` :std:`core::panic`.
It is a static error if the evaluation of a :t:`constant expression` results in
a :t:`value` that is unaligned.

.. rubric:: Undefined Behavior

:dp:`fls_hOIImCr1c6IF`
It is undefined behavior to convert a :t:`pointer` that has :t:`provenance` into a non-:t:`pointer type` in a :t:`constant context`.
Copy link
Copy Markdown
Contributor

@PLeVasseur PLeVasseur Apr 22, 2026

Choose a reason for hiding this comment

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

I think this sentence captures only one consequence of the upstream rule. In reference#2091, the normative const-eval restriction is broader: integer-like values must not carry provenance, and pointer-like values must either carry no provenance or consist of fragments of the same original pointer value in the correct order. Would it make sense to spec that broader rule, and then treat the ptr-to-non-pointer case here as an implication or example? If the main rule ends up living with shared const/static-initializer material, this sentence could then point back to that broader restriction.


.. rubric:: Dynamic Semantics

:dp:`fls_tg0kya5125jt`
Expand Down
6 changes: 6 additions & 0 deletions src/values.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,12 @@ The :t:`expression` of a :t:`constant initializer` shall be a
The value of a :t:`constant` is determined by evaluating its
:t:`constant initializer`.

:dp:`fls_LmPbrh0Cba8g`
The :t:`type representation` of the :t:`value` of a :t:`constant initializer` or :t:`static initializer` must only contain bytes with :t:`provenance` where all bytes of some original :t:`pointer` are in the correct order.

:dp:`fls_nwgIMLkvD2Ol`
:dt:`Provenance` is the memory that a :t:`pointer` has permission to access, the timespan during which it can acesss that memory, and if it can access the memory for writes.
Copy link
Copy Markdown
Contributor

@kirtchev-adacore kirtchev-adacore Apr 21, 2026 •
edited by rustbot
Loading

Choose a reason for hiding this comment

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

Where did you get this definition from? To me, "provenance" is a property (of something, TBD). According to Merriam-Webster, "provenance" is the origin or source, or the history of ownership.

View changes since the review

Copy link
Copy Markdown
Member Author

@tshepang tshepang Apr 21, 2026

Choose a reason for hiding this comment

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

https://doc.rust-lang.org/stable/core/ptr/index.html#provenance

maybe I should just call it pointer provenance

Copy link
Copy Markdown
Contributor

@PLeVasseur PLeVasseur Apr 22, 2026

Choose a reason for hiding this comment

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

I think the bigger risk here is not just where this definition came from, but that it commits FLS to a general provenance model that the upstream Reference text did not define in these PRs. The local wording reads more like a paraphrase of pointer access permissions, while the neighboring rules are about bytes carrying provenance and fragments of an original pointer value. Would it be safer to avoid defining provenance locally unless we have upstream wording to anchor it, or else narrow the term explicitly to the byte-level notion needed by this rule?


.. rubric:: Dynamic Semantics

:dp:`fls_xezt9hl069h4`
Expand Down
Loading