document preservation of padding in operations on pointers#695
document preservation of padding in operations on pointers#695
Conversation
| The representation of the 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
https://doc.rust-lang.org/stable/core/ptr/index.html#provenance
maybe I should just call it pointer provenance
There was a problem hiding this comment.
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?
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
Co-authored-by: Hristian Kirtchev <60669983+kirtchev-adacore@users.noreply.github.com>
| .. 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`. |
There was a problem hiding this comment.
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.
| The representation of the 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. |
There was a problem hiding this comment.
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?
3 participants
This is as far as I "understand" these things, and is based on these 2 PRs