No conversions from integer take place here. Rather it's a matter of effective type rules for allocated storage with memcpy-like char copying.
Conversation
I'm not talking about the specific example that was presented but rather the response to it. They are likely to more formally define these things in C2X and some early drafts like cl.cam.ac.uk/~pes20/cerberu show what that could end up looking like.
3
1
Thanks for the link. That proposal is still a pile of overcomplicated nonsense. The problems are all trivially solved *without breaking anything* by giving all the hard cases "wildcard provenance".
1
Note that the proposed text breaks lots of important valuable use cases like xor lists.
2
Clang and GCC already consider that broken per the standard. It was also very explicitly made to be broken in C++ already, which tends to trickle back to the C standard since it's a lot of the same people making the decisions and they reference each other as justifications.
2
open-std.org/jtc1/sc22/wg14 appears to be a more recent draft of what I linked earlier by the way. We'll see how they end up deciding to clarify it for C2X. My feeling is they will bend over backwards to permit / attempt to formalize existing real world compiler interpretations.
1
I'm not arguing that what Clang and GCC currently do is correct, but I am saying that they currently do it, and that it's likely to become officially correct *because* they want to it. Type-based alias analysis is similar. They tried to allow it, and will readjust it as needed.
1
1
Type-based alias analysis is possible to specify consistently, and has clear reasons you want to do it. This provenance stuff has absolutely no motivation, because deriving pointers from ints/reprs is rare, and when you do it, you actually mean it.
2
1
The motivation for it isn't to optimize cases where the conversions are used but rather cases where they're not by being able to assume that the information isn't subtly leaked out and then used to construct an aliasing pointer somewhere else that the compiler doesn't know about.
1
Assuming any pointer whose representation was read or which was cast to an integer type has leaked unboundedly has essentially no cost; you don't do these things unless you mean to.
1
It's not just an explicit conversion that the compiler needs to be concerned about, but also implicit ways of the value being leaked out such as via comparisons with other pointers or calculation of differences which the compiler can't determine aren't letting the value escape.
It's part of why pointer comparisons are undefined between different objects and using the pointer value after free for something like a comparison is undefined. Also, conversion to int is often used in some calculations especially for `p - q` where it might otherwise overflow.
1
Conversion to int is not a reasonable way to do p-q, assuming p-q is defined to begin with. Rather the implementation is broken if ptrdiff_t is not sized appropriately for the sizes of arrays it allows.
Comparisons and differences are only valid within the same array, so they don't leak anything. To compare or difference outside that you need a conversion to [u]intptr_t, which provides the point of escape.