rsmith added a comment.

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.)

`nullptr_t` is modeled roughly as if:

  struct alignas(void*) nullptr_t {
    template<typename T> operator T*() { return nullptr; }
  }

and as with that struct type,`bit_cast` of `nullptr_t` to some other type 
should (presumably) result in an uninitialized value.


Repository:
  rC Clang

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

Reply via email to