[Bug c/67999] Wrong optimization of pointer comparisons

["danielmicay at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999

--- Comment #20 from Daniel Micay <danielmicay at gmail dot com> ---
> I think several issues are mixed:

A conforming C implementation requires either fixing both the compiler and libc
functions to handle > PTRDIFF_MAX objects or preventing them from being
allocated via standard mechanisms (and *ideally* documenting the restriction).
Since there are many other issues with > PTRDIFF_MAX objects (p - q, read/write
and similar uses of ssize_t, etc.) and few reasons to allow it, it really makes
the most sense to tackle it in libc.

> Is it documented?

I don't think musl has documentation like that in general.

> This terminology is quite misleading. It's neither signed nor unsigned. Pointer operand is unsigned while offsets are signed.

Agreed.

> How buggy? Are there bugs filed? Searching for PTRDIFF_MAX finds Zarro Boogs.

It hasn't been treated as a systemic issue or considered as something related
to PTRDIFF_MAX. You'd need to search for issues like ssize_t overflow to find
them. If you really want one specific example, it looks like there's at least
one case of `end - start` in stdlib/qsort.c among other places (char *mid = lo
+ size * ((hi - lo) / size >> 1);). I don't think fixing every usage of `end -
start` on arbitrarily sized objects is the right way to go, so it's not
something I'd audit for and file bugs about.

I did do some testing a while ago by passing > PTRDIFF_MAX size objects to the
standard libc functions taking pointer and size parameters so I'm aware that
it's problematic.

> This is the same restriction as in C11 which is satisfied in the provided example. (If one large number is a problem replace "buf + len" by "(int *)buf + len / sizeof(int)".) So it should work in Clang?

The length is cast to a signed integer of the same size and that negative
signed offset is given as an argument to the inbounds GEP instruction, which is
undefined since it wraps.

> For this to work a compiler have to support for working with huge objects, right?

Well, they might just need a contiguous allocation without the need to actually
use it all at once. It doesn't necessarily require compiler support, but it
could easily go wrong without compiler support if the semantics of the
implementation aren't clearly laid out (and at the moment it's definitely not
documented).