rjmccall added a comment. In D62825#1542639 <https://reviews.llvm.org/D62825#1542639>, @rsmith wrote:
> In D62825#1542597 <https://reviews.llvm.org/D62825#1542597>, @rjmccall wrote: > > > 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. > > > Note that `bit_cast` supports casting not just from fundamental types but > also from aggregates (which might contain a `nullptr_t`). At runtime, we're > going to `memcpy` from the source object, which will leave the bits in the > destination corresponding to `nullptr_t` subobjects in the source > uninitialized (if they were in fact uninitialized in the source object, which > they might be). It would be unreasonable to initialize the bits in the > `bit_cast` result during compile-time evaluation but not during runtime > evaluation -- compile-time evaluation is supposed to diagnose cases that > would be undefined at runtime, not define them. > > In my view, the mistake was specifying `nullptr_t` to have the same size and > alignment as `void*`; it should instead be an empty type. Only confusion > results from making it "look like" a pointer type rather than just being an > empty tag type. Perhaps, but that's clearly unfixable without breaking ABI, whereas the object-representation issue is fixable by, at most, requiring a few stores that might be difficult to eliminate in some fanciful situations. 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
