Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC: Rust Has Provenance

github.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: RFC: Rust Has Provenance

#11

Post by Rusky »

Buttons840 wrote: post #9
vaylian wrote: post #2

> The pointer's "provenance" says where in memory the pointer is allowed to access when. Is that the definition of provenance or is there a wider definition that we should know?

Isn't this a definition of lifetimes too? A lifetime is some set of memory a reference may refer to. Consider: fn foo (x: &'a str, y: &'b str) -> &'a str Aren't 'a and 'b sets of memory a reference can refer to? As far as this function call is concerned, both 'a and 'b will live throughout, so it's not about life and death, it's about what memory the references may refer too. Is a lifetime and a "provenance" the same…

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri (https://github.com/rust-lang/miri) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules.

Lifetimes are a static approximation of provenance. They are erased after being validated by the borrow checker, and do not exist in Miri or have any impact on what transformations the optimizer may perform. In other words, the provenance rules allow a superset of what the borrow checker allows.

Re: RFC: Rust Has Provenance

#12

Post by Buttons840 »

Georgelemental wrote: post #10
Buttons840 wrote: post #9

Earlier quoted context omitted.

Isn't this a definition of lifetimes too? A lifetime is some set of memory a reference may refer to. Consider: fn foo (x: &'a str, y: &'b str) -> &'a str Aren't 'a and 'b sets of memory a reference can refer to? As far as this function call is concerned, both 'a and 'b will live throughout, so it's not about life and death, it's about what memory the references may refer too. Is a lifetime and a "provenance" the same…

> Aren't 'a and 'b sets of memory a reference can refer to? No, the set of memory the reference refers to is encoded by the reference's bits. Two references with the same lifetime can refer to different memory, and vice-versa. Lifetimes determine when the reference is valid.

I was speaking more abstractly.

Strictly speaking, a pointer points to 1 address, not a set.

Abstractly speaking, a lifetime represents a set of memory that lives a certain length of time, and thus also represents the set of memory a reference with that lifetime can reference.

It's just a different way of thinking about lifetimes which helped me understand them.

Re: RFC: Rust Has Provenance

#13

Post by Buttons840 »

Rusky wrote: post #11
Buttons840 wrote: post #9

Earlier quoted context omitted.

Isn't this a definition of lifetimes too? A lifetime is some set of memory a reference may refer to. Consider: fn foo (x: &'a str, y: &'b str) -> &'a str Aren't 'a and 'b sets of memory a reference can refer to? As far as this function call is concerned, both 'a and 'b will live throughout, so it's not about life and death, it's about what memory the references may refer too. Is a lifetime and a "provenance" the same…

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri ( https://github.com/rust-lang/miri ) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules. Lifetimes are a static approximation of provenance. They are…

So this is about solidifying very specific semantics that are of more concern to projects like Miri than it is to regular users?

Speaking of Miri, is the long term goal to say for certain whether or not a program execution encountered UB? (Which is, of course, different than verifying it before execution at compile time.)

Re: RFC: Rust Has Provenance

#14

Post by Rusky »

Buttons840 wrote: post #13
Rusky wrote: post #11

Earlier quoted context omitted.

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri ( https://github.com/rust-lang/miri ) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules. Lifetimes are a static approximation of provenance. They are…

So this is about solidifying very specific semantics that are of more concern to projects like Miri than it is to regular users? Speaking of Miri, is the long term goal to say for certain whether or not a program execution encountered UB? (Which is, of course, different than verifying it before execution at compile time.)

It is about solidifying semantics, but those semantics are still a concern to regular users who are writing `unsafe` code, not just Miri.

As I understand it, Miri would like to be certain about the presence/absence of the UB of any particular program execution, but there will probably always be some cases it can't catch.

Re: RFC: Rust Has Provenance

#15

Post by Georgelemental »

Buttons840 wrote: post #12
Georgelemental wrote: post #10

Earlier quoted context omitted.

> Aren't 'a and 'b sets of memory a reference can refer to? No, the set of memory the reference refers to is encoded by the reference's bits. Two references with the same lifetime can refer to different memory, and vice-versa. Lifetimes determine when the reference is valid.

I was speaking more abstractly. Strictly speaking, a pointer points to 1 address, not a set. Abstractly speaking, a lifetime represents a set of memory that lives a certain length of time, and thus also represents the set of memory a reference with that lifetime can reference . It's just a different way of thinking about lifetimes which helped me understand them.

> a pointer points to 1 address, not a set.

Rust "fat pointers" like `&str` contain a length as well.

> represents the set of memory a reference with that lifetime can reference.

No, you can have memory that is alive for a particular lifetime but that you are not allowed to access via a pointer with said lifetime (because it's out of bounds).

Re: RFC: Rust Has Provenance

#16

Post by digama0 »

Buttons840 wrote: post #13
Rusky wrote: post #11

Earlier quoted context omitted.

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri ( https://github.com/rust-lang/miri ) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules. Lifetimes are a static approximation of provenance. They are…

So this is about solidifying very specific semantics that are of more concern to projects like Miri than it is to regular users? Speaking of Miri, is the long term goal to say for certain whether or not a program execution encountered UB? (Which is, of course, different than verifying it before execution at compile time.)

> Speaking of Miri, is the long term goal to say for certain whether or not a program execution encountered UB? (Which is, of course, different than verifying it before execution at compile time.)

That's more than a long term goal, that's the present behavior, to the extent that the UB rules are defined in the first place. Miri will tell you when it has to make approximating assumptions (e.g. accessing FFI or using nondeterministic operations), and it doesn't happen very often. This is very much the intent of the tool.

Re: RFC: Rust Has Provenance

#17

Post by aredox »

foldr wrote: post #7
_nalply wrote: post #5

Earlier quoted context omitted.

Probably just a mistake. I just would assume that the word "when" is superfluous and respond in a way that allows the asker to correct their mistake but not invest too much in an answer because the assumption might be wrong. I am picky in language as well, so I understand where you are coming from. But I discovered that LLMs often answered anyway when my question was incomplete or contained mistakes and they got it c…

It’s just a multiple wh construction as in Who arrived when? which you might answer with e.g. “John on Tuesday and Mary on Wednesday”. This one is a bit harder to parse because it’s longer, but the answers will be something like “it can access region A at time T, region B at time T’, …”

Thanks!I really couldn't recognise it was this construction here!

Re: RFC: Rust Has Provenance

#18

Post by quelsolaar »

Provenance In C and Rust, essentially mean that each object, lives in its own memory space, and you cant travel between them. You cant use a pointer to one object, add an offset and get a valid pointer to another object.

This is key to a lot of compiler optimizations. It is de facto in C compilers, and therefor in a lot of compiler infrastructure used by other languages. There is an attempt to make it more clearly defined in the C standard:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3005.pdf

Re: RFC: Rust Has Provenance

#19

Post by ralfj »

quelsolaar wrote: post #18

Provenance In C and Rust, essentially mean that each object, lives in its own memory space, and you cant travel between them. You cant use a pointer to one object, add an offset and get a valid pointer to another object. This is key to a lot of compiler optimizations. It is de facto in C compilers, and therefor in a lot of compiler infrastructure used by other languages. There is an attempt to make it more clearly de…

It's not just per-object. When you consider things like `restrict` pointers in C, and the aliasing model in Rust (e.g. Stacked Borrows), you have provenance distinctions even within a single allocated object.
Post reply on HN