4 ms·

For what it's wort, I agree with a lot of the criticism you raise. But I think it's a bit misdirected to blame this proposal - the C implementors and standards

For what it's wort, I agree with a lot of the criticism you raise. But I think it's a bit misdirected to blame this proposal - the C implementors and standards people went down this road a long time ago, and arguably the proposal cleans it up and puts it on a sounder footing. What we now realize is that the C abstract machine is a much more complicated and slippery idea than was originally hoped. The strictly typed world does not blend smoothly with an assembly-like model where pointers are simply integers used to index into memory. But staying strictly in the latter model is also not viable, as it precludes some optimizations that we really want to do. Incidentally, this is one of the big things holding up a formal spec for Rust as well, as Rust also has a strictly typed fragment (even more so than C) but C-like pointers as well. The semantics of all this more or less inherit from LLVM, but as we're finding out, LLVM is not particularly sound when it comes to these difficult cases, namely converting back and forth between pointers and integers, and doing nontrivial manipulation of those integers.

dooglius 5y ago
> C implementors and standards people went down this road a long time ago I'm aware of that, but just because something was done before doesn't justify it being done more aggressively in the future. This isn't really an academic or tilting-at-windmills complaint either; most existing code, for better or for worse, uses pointers more broadly than the strict sense the standard allows, and more aggressive optimizations in this area are all but guaranteed to break existing code in dangerous ways. > But staying strictly in the latter model is also not viable, as it precludes some optimizations that we really want to do. Does that really make it "not viable" though? I would counter that a strictly typed model is not viable in that it precludes optimizations I want to do, as a programmer! For example: xor linked lists, doing anything with shadowed memory, using packed structures or more generally any misaligned loads on architectures that support it (which is most of the important ones), binary search trees over pointers, parsing nearly any binary file format or network protocol without lots of memcpys... and that's just off the top of my head >this is one of the big things holding up a formal spec for Rust as well I'm not familiar with LLVM's internals, but does anything preclude these optimizations being gated by an attribute that could get set (by default) by a Rust frontend but not (by default) by C frontend? Gating with attributes is already done with e.g. __attribute__((may_alias)) so it would seem that this ought to be doable. Heck, if you give me an opt-in __attribute__((contrete_semantics)) and keep the defaults UB I'd be more than content.

dooglius 5y ago

> C implementors and standards people went down this road a long time ago I'm aware of that, but just because something was done before doesn't justify it being done more aggressively in the future. This isn't really an academic or tilting-at-windmills complaint either; most existing code, for better or for worse, uses pointers more broadly than the strict sense the standard allows, and more aggressive optimizations in this area are all but guaranteed to break existing code in dangerous ways. > But staying strictly in the latter model is also not viable, as it precludes some optimizations that we really want to do. Does that really make it "not viable" though? I would counter that a strictly typed model is not viable in that it precludes optimizations I want to do, as a programmer! For example: xor linked lists, doing anything with shadowed memory, using packed structures or more generally any misaligned loads on architectures that support it (which is most of the important ones), binary search trees over pointers, parsing nearly any binary file format or network protocol without lots of memcpys... and that's just off the top of my head >this is one of the big things holding up a formal spec for Rust as well I'm not familiar with LLVM's internals, but does anything preclude these optimizations being gated by an attribute that could get set (by default) by a Rust frontend but not (by default) by C frontend? Gating with attributes is already done with e.g. __attribute__((may_alias)) so it would seem that this ought to be doable. Heck, if you give me an opt-in __attribute__((contrete_semantics)) and keep the defaults UB I'd be more than content.