4 ms·

Well, you can't "just" cast any of Rust's integers to a pointer because they're not necessarily the same size (one of the changes to Rust is the decision that u

Well, you can't "just" cast any of Rust's integers to a pointer because they're not necessarily the same size (one of the changes to Rust is the decision that usize is not the same size as a pointer only the same size as the pointer address), but C++ uintptr_t is in fact guaranteed to be the same size and presumably the compiler might just model it as an address the same as a pointer. Today there are no settled provenance rules for C or C++ but there is a TS for C explaining PNVI-ae-udi. Under that model if we cast a pointer to uintptr_t we're exposing the provenance of that pointer. In Rust's Exposed Provenance API we're not promised that this is even possible on every target (if we imagine compiling Rust for a CHERI target clearly expose_provenance may not compile to any actual code, maybe the compiler barfs) but in C we're guaranteed the actual raw bits so we're allowed to, for example, display them to the user and under this TS the associated provenance is thereby exposed - so we can have the user later input an arbitrary integer, turn it into a pointer and the resulting pointer must work if they gave us the right number and that pointer would still be valid! Is that a good idea? No. But it's very on brand for C and might become the de facto or even de jure semantic for pointer provenance in C++ too.

uecker 2y ago
The reason this is a really good idea is because is sometimes needed in the real world and with PNVI-ae-udi is just works. Also the alternative models have horrible semantics, e.g. either because you have provenance via integers (where algebraic properties of mathematics breaks) or because you get really subtle semantics that is hard to reason about (all the angelic / demonic indeterminism ideas).
- tialaramex 2y ago
  Are you telling me that, if you could start over somehow, you'd suggest K&R should specify PNVI-ae-udi ? Or do you mean (which I accept) only that well, too bad, PNVI-ae-udi is the best we could do with C given where we started from 20+ years ago? I actually think there's yet significant risk that this is swamped by the "Bag of bits" people despite all your hard work. There are plenty of WG21 submissions whose subtext can be read that way, they want their "high level assembler" and they don't care that it's a myth and can't be made real, they're not taking "No" for an answer. So, congratulations on the TS.
  - uecker 2y ago
    I actually think PNVI-ae-udi is pretty good semantic model for a systems programming language, considering that it is the essentially only reasonable model on how to combine abstract pointers with low-level integer based pointers in a way that makes it work well. I am not entirely sure I would allow one-after points if I were to design a language from scratch, but I haven't made up my mind about it.
    - tialaramex 2y ago
      While it makes sense that you landed on PNVI-ae-udi for C because of its prior baggage, I don't see how this makes a good choice for a language without that baggage. For one thing, I'm pretty sure systems languages don't need to combine these two ideas at all. In C there's a single pointer type and so it has both uses too bad, but in a hypothetical new language you don't need to do that and I think it would be clearer not to.
      - uecker 2y ago
        I am not sure what you mean by "baggage", "two ideas" etc. If you boil it down to how computers work and want to have an abstract pointer model at the same time, there is not much design space left.
        tialaramex 2y ago
        The good news is that you already listed the two separate ideas. In C you need to have a single type which embodies both contradictory ideas, but that's actually a choice, albeit one it's far too late for C to change now. The fact that choices you made in the past can't subsequently be changed is baggage. Even if you decide tomorrow that this was a waste of your time and you should never have worked on the provenance problem, you can't have that time back. [that's an example of personal baggage, in the case of C the early choice to only have the single type for both purposes is the baggage]
IshKebab 2y ago
> Well, you can't "just" cast any of Rust's integers to a pointer because they're not necessarily the same size (one of the changes to Rust is the decision that usize is not the same size as a pointer only the same size as the pointer address You can though, in practice on a non-CHERI system and if you avoid optimisations. I haven't looked but I would expect the change you mentioned was made precisely because of CHERI, where a pointer and address are different sizes. On all other platforms Rust supports they are the same.

uecker 2y ago

The reason this is a really good idea is because is sometimes needed in the real world and with PNVI-ae-udi is just works. Also the alternative models have horrible semantics, e.g. either because you have provenance via integers (where algebraic properties of mathematics breaks) or because you get really subtle semantics that is hard to reason about (all the angelic / demonic indeterminism ideas).

tialaramex 2y ago
Are you telling me that, if you could start over somehow, you'd suggest K&R should specify PNVI-ae-udi ? Or do you mean (which I accept) only that well, too bad, PNVI-ae-udi is the best we could do with C given where we started from 20+ years ago? I actually think there's yet significant risk that this is swamped by the "Bag of bits" people despite all your hard work. There are plenty of WG21 submissions whose subtext can be read that way, they want their "high level assembler" and they don't care that it's a myth and can't be made real, they're not taking "No" for an answer. So, congratulations on the TS.
- uecker 2y ago
  I actually think PNVI-ae-udi is pretty good semantic model for a systems programming language, considering that it is the essentially only reasonable model on how to combine abstract pointers with low-level integer based pointers in a way that makes it work well. I am not entirely sure I would allow one-after points if I were to design a language from scratch, but I haven't made up my mind about it.
  - tialaramex 2y ago
    While it makes sense that you landed on PNVI-ae-udi for C because of its prior baggage, I don't see how this makes a good choice for a language without that baggage. For one thing, I'm pretty sure systems languages don't need to combine these two ideas at all. In C there's a single pointer type and so it has both uses too bad, but in a hypothetical new language you don't need to do that and I think it would be clearer not to.
    - uecker 2y ago
      I am not sure what you mean by "baggage", "two ideas" etc. If you boil it down to how computers work and want to have an abstract pointer model at the same time, there is not much design space left.
      - tialaramex 2y ago
        The good news is that you already listed the two separate ideas. In C you need to have a single type which embodies both contradictory ideas, but that's actually a choice, albeit one it's far too late for C to change now. The fact that choices you made in the past can't subsequently be changed is baggage. Even if you decide tomorrow that this was a waste of your time and you should never have worked on the provenance problem, you can't have that time back. [that's an example of personal baggage, in the case of C the early choice to only have the single type for both purposes is the baggage]

IshKebab 2y ago

> Well, you can't "just" cast any of Rust's integers to a pointer because they're not necessarily the same size (one of the changes to Rust is the decision that usize is not the same size as a pointer only the same size as the pointer address You can though, in practice on a non-CHERI system and if you avoid optimisations. I haven't looked but I would expect the change you mentioned was made precisely because of CHERI, where a pointer and address are different sizes. On all other platforms Rust supports they are the same.