Conversation

Replying to and
C standard retroactively turns things into undefined behavior regularly. They see their job as largely standardizing real world implementations. If compiler authors want something badly enough, they'll get it, because they'll do it and the standard will change. Likely for this.
2
1
Replying to and
The standard currently implies that optimization based on pointer provenance is not really a thing. It omits talking about it and says nothing about it being undefined. However, compilers do it, and the standard will likely be brought in line with what compilers choose to do.
2
2
Replying to and
Safe Rust code is actually meant to be properly sound and completely well defined / specified. However, unsafe Rust code pretty much just follows the same kind of rules as C based on the LLVM choices. Despite not having a formal spec it's better specified in certain ways though.
1
1
Replying to and
Rust doesn't do TBAA and doesn't really need it due to the &T and &mut T restrictions so that's a lot of complexity that's avoided. It doesn't have the pointer provenance rules but LLVM doesn't really document what they do and my generic wording was lost when they updated it.
2
2
Replying to and
The list there is almost the same as my original list but someone declared it complete/exhaustive when it originally didn't claim that, and the part about aliasing was ruined. Whoever replaced that seemed to miss a lot of the point. Not my problem to resolve though.
1
1
Rust's rules for UB in unsafe code will definitely be a lot simpler than C and it doesn't have UB in safe code. I strongly dislike the style that the documentation was remade into and part of that is it deliberately eschews accuracy in favor of being amusing and comforting.
1
1
Show replies