>but you must be aware that you might get back an entirely new pointer
Which is super fun if someone else adds code that keeps a copy of the pointer, not knowing that it might change.
Incidentally, is that possibility realistic in a 64-bit system? It seems like the addresses could easily be spaced out enough that you would never actually expect to see a realloc return a different pointer.
They could, but it would be extremely inefficient for small allocations. Pages are 8 KiB minimum, so it would waste memory, bloat up the page tables, and ruin cache efficiency.
Hmm, I see what you mean. But it seems like that could be solved by more sophisticated virtual memory management, although it seems like it would essentially take an entire other layer of virtualization to make it work, which might have other performance consequences.
For example, jemalloc stores medium-sized allocations in big contiguous buffers, binned by size rounded up to 16 bytes. So if you realloc to a different size class, your pointer will change, because you need to move to a different big buffer.
Which is super fun if someone else adds code that keeps a copy of the pointer, not knowing that it might change.
Incidentally, is that possibility realistic in a 64-bit system? It seems like the addresses could easily be spaced out enough that you would never actually expect to see a realloc return a different pointer.