←back to thread

The provenance memory model for C

(gustedt.wordpress.com)
224 points HexDecOctBin | 1 comments | 30 Jun 25 09:25 UTC | HN request time: 0s | source
Show context
nikic ◴[30 Jun 25 20:45 UTC] No.44427669[source]▶
At least at a skim, what this specifies for exposure/synthesis for reads/writes of the object representation is concerning. One of the consequences is that dead integer loads cannot be eliminated, as they may have an exposure side effect. I guess C might be able to get away with it due to the interaction with strict aliasing rules. Still quite surprised that they are going against consensus here (and reduces the likelihood that these semantics will get adopted by implementers).
replies(4): >>44427836 #>>44428359 #>>44428989 #>>44432092 #
ben0x539 ◴[30 Jun 25 23:24 UTC] No.44428989[source]▶
Can you say more about what the consensus is that this is going against?
replies(1): >>44437131 #
1. nikic ◴[01 Jul 25 19:14 UTC] No.44437131[source]▶
That type punning through memory does not expose or synthesize memory. There are some possible variations on this, but the most straightforward is that pointer to integer transmutes just return the address (without exposure) and integer to pointer transmutes return a pointer with nullary provenance.