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.
https://github.com/cplusplus/draft/blob/n4842/source/expressions.tex#L5959-L5971
> 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?

-- 
k_satoda