rjmccall added a comment. In D62825#1542374 <https://reviews.llvm.org/D62825#1542374>, @rsmith wrote:
> In D62825#1542309 <https://reviews.llvm.org/D62825#1542309>, @rjmccall wrote: > > > In D62825#1542301 <https://reviews.llvm.org/D62825#1542301>, @rsmith wrote: > > > > > In D62825#1542247 <https://reviews.llvm.org/D62825#1542247>, @rjmccall > > > wrote: > > > > > > > In what sense is the bit-pattern of a null pointer indeterminate? > > > > > > > > > The problem is not null pointers, it's `nullptr_t`, which is required to > > > have the same size and alignment as `void*` but which comprises only > > > padding bits. (Loads of `nullptr_t` are not even permitted to touch > > > memory...). > > > > > > I mean, I know this is C++ and the committee loves tying itself in knots to > > make the language unnecessarily unusable, but surely the semantics of > > bitcasting an r-value of type `nullptr_t` are intended to be equivalent to > > bitcasting an r-value of type `void*` that happens to be a null pointer. > > > I don't follow -- why would they be? `bit_cast` reads the object > representation, which for `nullptr_t` is likely to be uninitialized, because > the type contains only padding bits. (Note that there is formally no such > thing as "bitcasting an rvalue". `bit_cast` takes an lvalue, and reinterprets > its storage.) I agree that the problem is that the object representation of `nullptr_t` is wrong, but it seems absurd to me that we're going to bake in an absurd special case (from the user's perspective) to `bit_cast` because we consider that representation unfixable. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62825/new/ https://reviews.llvm.org/D62825 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
