Skip to content

Commit

Permalink
clarify wording; link to C committee logs for vote on provenance TS
Browse files Browse the repository at this point in the history
  • Loading branch information
RalfJung committed Jan 26, 2024
1 parent 3448224 commit 0c165b0
Showing 1 changed file with 38 additions and 4 deletions.
42 changes: 38 additions & 4 deletions text/0000-rust-has-provenance.md
Original file line number Diff line number Diff line change
Expand Up @@ -163,9 +163,10 @@ Sanitizers and undefined behavior detectors like [Miri](https://github.com/rust-
[^exists]: This is the same sense in which the distinction between initialized and uninitialized memory "exists" during program execution, even though it cannot be observed on most hardware.
[^erase]: It is of course still possible to erase provenance during compilation, *if* the target that we are compiling to does not actually do the access checks that the abstract machine does. What is not safe is having a language operation that strips provenance, and inserting that in arbitrary places in the program.

*Historical note:* The author assumes that provenance in C started out purely descriptively.
However, the moment compilers started doing optimizations that exploit undefined behavior depending on the provenance of a pointer, provenance became prescriptive.
*Historical note:* The author assumes that provenance in C was originally intended to be purely descriptive.
However, the moment compilers started doing optimizations that exploit undefined behavior depending on the provenance of a pointer, provenance of de-facto-C became prescriptive.
A lot of the confusion around provenance arises from the fact that many people still think it is purely descriptive.
The standard has never been updated to clarify this, but in 2022 the committee has accepted a Technical Specification that does explicitly state that C has prescriptive provenance.
The point of this RFC is that Rust has *prescriptive* provenance.

# Guide-level explanation
Expand Down Expand Up @@ -246,9 +247,42 @@ That said, (2) would still be a valid option for surface Rust, so this RFC delib
# Prior art
[prior-art]: #prior-art

* "[A Provenance-aware Memory Object Model for C](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3005.pdf)"
* "[N3057: A Provenance-aware Memory Object Model for C](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3057.pdf)"
describes how the C standard is attempting to fit provenance concepts into C.
This technical specification has been accepted unanimously by the C standards committee, but is not part of the official ISO standard.
This [technical specification](https://www.iso.org/standard/81899.html) has been accepted unanimously by the C standards committee, but is not (yet) part of the official ISO standard.

<details><summary>C committee minutes</summary>

[2022-01-31 Final Meeting Minutes](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2991.pdf):

Straw poll: Does WG14 wish to see TS6010 working draft (N2676 or something similar) in some future version of the standard?<br>
21/0/1. Clear consensus.<br>
Straw poll: Does WG14 wish to see TS6010 working draft (N2676 or something similar) in C23?<br>
10/8/5. Clear indication people think this is important.<br>
Straw poll: (Opinion) Is WG 14 willing to move TS 6010 to DTS ballot as it stands now?<br>
19/1/3. The committee is OK to move forward.<br>
(the numbers are yes/no/abstain)

[2022-05-16 - 2022-05-20 Final Meeting Minutes](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3036.pdf):

Straw poll: (decision) Does WG14 want to move to a DTS ballot for TS 6010?<br>
Result: 18-0-0 (consensus)<br>
Uecker: would like to mention that other languages, especially Rust, are adopting this, so now is a useful time to progress.<br>

[2023-01-23 - 2023-01-28 Final Meeting Minutes](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3153.pdf):

Keaton: any objections to a CD ballot for TS 6010?<br>
(none, unanimous consent)<br>
DECISION: Gustedt’s document will go to SC22 and start the two-month ballot process this week.<br>
One month available if needed for ballot resolution.<br>
Sewell: can we start with ISO working in parallel?<br>
Keaton: yes, ISO has volunteered to start its review early.<br>
ACTION: Keaton to submit TS 6010 to ISO early.<br>
ACTION: Gustedt to make up an N-document for TS 6010.<br>

(That document became [N3057](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3057.pdf).)

</details>

### Prior discussion in Rust

Expand Down

0 comments on commit 0c165b0

Please sign in to comment.