2 ms·

Provenance (outside programming this is the distinction between "I reckon this old table is a few hundred years old" and "Here is the bill of sale from when my

Provenance (outside programming this is the distinction between "I reckon this old table is a few hundred years old" and "Here is the bill of sale from when my grandfathers ancestors had the table made from the old tree where that cherry tree is now in 1620") not Providence. In Rust pointer provenance is a well defined language feature and if you go to the language docs you can read how it interacts with your use of raw pointers and the twin APIs provided for this. In C the main ISO document just says basically here be dragons. There's an additional TS from 2023 with better explanation, but of course your C compiler even if it implemented all of C23 needn't necessarily implement that TS. Also of course the API is naturally nowhere near as rich as Rust's. C is not a language where pointers have an "addr" method so they also don't need a separate exposure API. I suspect that in Zig none of this is clearly specified.

uecker 2y ago
LLVM has optimization not consistent with TS 6010 or any consistent model and this should affect Rust as well.
- tialaramex 2y ago
  Sure, I'm interested in whether any of those bugs affect say, Cranelift because the Cranelift did, as I understand it, a much better job of coming up with a coherent IR semantic so unlike LLVM fixing bugs in this layer isn't as scary if it's necessary for them. It is definitely possible to write Rust or (with more difficulty, legal C) which should show off something about provenance semantics and instead the LLVM backend just emits contradictory "One and two are the same number" type nonsense code. In C of course they can say well, since the ISO document pointedly does not specify how this works, maybe one and two really are the same number, although nobody actually wants that - in Rust that's definitely a bug but you will just get pointed at the corresponding LLVM bug for this issue, they know it's busted but it's hard to fix. I don't know whether fixing the LLVM bug magically makes it TS6010 compliant. If so that would be nice.

uecker 2y ago

LLVM has optimization not consistent with TS 6010 or any consistent model and this should affect Rust as well.

tialaramex 2y ago
Sure, I'm interested in whether any of those bugs affect say, Cranelift because the Cranelift did, as I understand it, a much better job of coming up with a coherent IR semantic so unlike LLVM fixing bugs in this layer isn't as scary if it's necessary for them. It is definitely possible to write Rust or (with more difficulty, legal C) which should show off something about provenance semantics and instead the LLVM backend just emits contradictory "One and two are the same number" type nonsense code. In C of course they can say well, since the ISO document pointedly does not specify how this works, maybe one and two really are the same number, although nobody actually wants that - in Rust that's definitely a bug but you will just get pointed at the corresponding LLVM bug for this issue, they know it's busted but it's hard to fix. I don't know whether fixing the LLVM bug magically makes it TS6010 compliant. If so that would be nice.