Date: Tue, 16 Sep 2025 05:44:03 +0000
> On Sep 15, 2025, at 19:25, Yongwei Wu via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
> Another angle: Can we make operator< on pointers
> implementation-defined, as more often than not it has quite
> well-defined behaviour? UB is a dangerous thing, and it is better to
> have as little UB as possible. (I also hate the fact that sometimes
> compilers utilize UB as a crazy licence to kill, and I do not want
> anything like that for something as simple as p1 < p2.)
It's not UB, is it? Rather, the result is unspecified: https://eel.is/c++draft/expr.rel#4 and https://eel.is/c++draft/expr.rel#5. If `p1` and `p2` don't point within the same array, then `p1 < p2` may yield true or it may yield false, but it can't impregnate your pets or summon nasal demons. It need not be consistent with any total or partial order, so `p1 < p2 && p2 < p1` could be true, as could `p1 < p2 && p2 < p3 && p3 < p1`. But there's no "license to kill".
>
> Another angle: Can we make operator< on pointers
> implementation-defined, as more often than not it has quite
> well-defined behaviour? UB is a dangerous thing, and it is better to
> have as little UB as possible. (I also hate the fact that sometimes
> compilers utilize UB as a crazy licence to kill, and I do not want
> anything like that for something as simple as p1 < p2.)
It's not UB, is it? Rather, the result is unspecified: https://eel.is/c++draft/expr.rel#4 and https://eel.is/c++draft/expr.rel#5. If `p1` and `p2` don't point within the same array, then `p1 < p2` may yield true or it may yield false, but it can't impregnate your pets or summon nasal demons. It need not be consistent with any total or partial order, so `p1 < p2 && p2 < p1` could be true, as could `p1 < p2 && p2 < p3 && p3 < p1`. But there's no "license to kill".
Received on 2025-09-16 05:44:06