In Windows, some invalid handle values are reinterpret_cast<void*>(-1), which means that doing a RAII wrapper templated on the invalid value doesn't works because the reinterpret_cast makes it invalid. In this case the "pointer" definitely leaks into runtime.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of connor horman via Std-Proposals
Sent: October 31, 2019 11:03
To: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Cc: connor horman <chorman64_at_[hidden]>; std-proposals_at_[hidden]
Subject: Re: [std-proposals] Allow reinterpret_cast (and static_cast from void*) in a constant expression in limited cases

That certainly poses an issue. Perhaps change it to require the pointer not be valid a pointer constant expression for the first one, so the pointer doesn't actually appear at runtime. This wouldn't affect the usefulness of the proposal, as the use-case is in computing hashcodes, and if known at runtime then it could be computed at runtime (even only once in the case of a static or constexpr variable). I don't believe the second part suffers from the same issue, though it might be possible in some situtations to encounter issues when the pointer leaks into runtime, but I can't think of any where the pointer would have different value representation from its validly reintepret_casted counterparts (when there is a
pointer-interconvertible) object.

On Thu, 31 Oct 2019 at 10:23, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
> On Thu, Oct 31, 2019 at 10:14 AM connor horman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> I propose to allow reinterpret_cast from pointer to integral, as well as the no-op/identity reintepret_cast in constant expressions. This particular version is useful in implementing hashcode algorithms at compile time, and to my knowledge bit_cast does not work for pointer types at compile time.
>
>
> I think this is a non-starter. Consider:
>
> // https://godbolt.org/z/Xd48ZV
> const int i = 42;
> constexpr int is_64_aligned(const int *p) {
> return reinterpret_cast<intptr_t>(p) % 64 == 0; } constexpr bool x
> = is_64_aligned(&i); int main(int argc, char **argv) {
> bool y = is_64_aligned(argc ? &i : nullptr);
> assert(x == y);
> }
>
> How is the compiler supposed to know at compile time what bits are in the runtime bit-pattern of `p`?
>
> –Arthur

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals