C++ Logo


Advanced search

What happened on "Null safety" in p0946r0 about p <=> nullptr

From: Kazutoshi Satoda <k_satoda_at_[hidden]>
Date: Thu, 5 Dec 2019 17:30:53 +0900
I found that, in the latest draft n4842, three-way comparison (<=>)
between an object pointer and a null pointer constant (p <=> nullptr)
yields unspecified result of type std::strong_ordering.
> If the composite pointer type is an object pointer type, p <=> q is of
> type std::strong_ordering. If two pointer operands p and q compare equal
> (7.6.10), p <=> q yields std::strong_ordering::equal; if p and q compare
> unequal, p <=> q yields std::strong_ordering::less if q compares greater
> than p and std::strong_ordering::greater if p compares greater than q
> (7.6.9). Otherwise, the result is unspecified.

I think it doesn't make sense and want p <=> nullptr be ill-formed.

Looking for issues already reported, I found https://wg21.link/p0946,
which had a section "Null safety", saying almost exactly what I think:
> The resolution of core issue 583 made relational comparisons against
> null pointer constants ill-formed. Such constructs have always been
> ill-formed in C, and appear likely to have only ever been valid in C++
> due to a wording oversight.
> However, the <=> operator oddly produces a std::strong_ordering result
> when comparing a null pointer constant against an object pointer,
> producing std::strong_ordering::equal when the pointer is null and an
> unspecified value (which could even be std::strong_ordering::equal!)
> otherwise. This seems to also be merely a wording oversight.

But the changes in the wording paper https://wg21.link/p1120 for p0946,
which had been adopted at 2018-06, didn't fix the above "Null safety"
issue, and the issue still remains in the latest draft.

Was it an oversight? Or something new was found to keep it unspecified?


Received on 2019-12-05 02:33:26