[libcxx-commits] [libcxx] [libc++] Avoid -Wzero-as-null-pointer-constant in operator<=> (PR #79465)

[Louis Dionne via libcxx-commits]

ldionne wrote:

> @frederick-vs-ja 
> > And I don't like that this wording introduces UB into something that ought to be compile-time checked. Maybe this is LWG issue material. WDYT?
> 
> [LWG3142](https://cplusplus.github.io/LWG/issue3142) is touching a similar area. There are also some conditions for UB which are only based on types, perhaps we should change all of such kinds of UB to IFNDR.

In this case, however, we want to say that e.g. `std::strong_ordering == 3` is a SFINAE-friendly failure, which is to say that `operator==(std::strong_ordering const&, int)` does not participate in overload resolution if the `int` happens not to be a literal `0`. That's a lot stronger than being IFNDR.

> @cor3ntin 
> My understanding is that enable_if is sfinae friendly, see https://godbolt.org/z/1xr9Wx38T But I can't think of a solution that would work for gcc?

Yes, that seems to work for Clang indeed. However since GCC doesn't support the attribute, we would silently accept arbitrary stuff like `std::strong_ordering == 4`. I think that is probably reasonable -- this is all technically UB so we're free to also accept it. But we might want to make it fail loudly to avoid people relying on that behavior?

@horenmar 

Given that Catch2 is relying on something that is technically UB and which happens to work only due to the exact way standard libraries implement this right now, I think it would be best to change the way Catch2 handles this. The ordering types are pretty special w.r.t. how they handle comparison, so I think it would make sense to handle them specifically in Catch2.


https://github.com/llvm/llvm-project/pull/79465