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).
