On Tue, 20 Jun 2023 at 11:45, Jonathan Wakely <jwak...@redhat.com> wrote:
> On Tue, 20 Jun 2023 at 09:21, Andreas Schwab wrote: > >> On Jun 20 2023, Jakub Jelinek via Gcc-patches wrote: >> >> > Is it safe even on 64bit targets? I mean, doesn't say PowerPC already >> allow >> > full 64-bit virtual address space? The assumption that one can't have >> > more than half of virtual address space allocations is true right now at >> > least on x86-64, aarch64 and others, but isn't that something that can >> > change with newer versions of CPUs without the need to recompile >> > applications (add another level or two of page tables)? >> >> At least s390 can allocate more than half the address space. That >> triggered a failure in gawk. >> > > Is PTRDIFF_MAX large enough to represent the difference between any two > pointers? > > What we're considering for libstdc++ is treating PTRDIFF_MAX as an upper > limit on allocation size. If there are targets that can really allocate a > 2^63 byte array, they won't be able to represent the difference between the > first element and the last element unless ptrdiff_t is wider than 64 bits. > Of course if we're talking about 32-bit targets then you only need a 64-bit ptrdiff_t to allow arrays larger than 2^31 bytes. In any case, PTRDIFF_MAX is still an upper limit (although for a 64-bit ptrdiff_t and a 32-bit address space, it's not a useful limit, because it's much much larger than the real limit).
