5 ms·
Technically, this needn't impact malloc, because dereferencing the "one past the end" address is still undefined. All you need is logic in your pointer arithmet
by cbsmith 10y ago
Technically, this needn't impact malloc, because dereferencing the "one past the end" address is still undefined. All you need is logic in your pointer arithmetic that essentially treats the past the end address as a special value (which normally would never need to be represented).
- int_19h 10y agoNot just pointer arithmetic; also pointer comparisons. One-past-the-end pointer must compare greater-than any other pointer into that array. So an implementation that could stick an array at the very end of the address space, and do wraparound for one-past-the-end so that it's represented by all bits zero, would then need to special-case that zero value when performing any pointer comparisons.
- cbsmith 10y agoOh, I was assuming a runtime that didn't do wraparound. If you are doing wraparound, you already have a ton of special case work you'd have to do. But yes, you'd need logic for pointer comparisons as well.
- int_19h 10y agoWouldn't it be very unusual for an environment to not do wraparound? I mean, on assembler level, pointers are just integers, and pretty much everything does wraparound arithmetics on those these days. But, so far as I can see, this case (allocating at the very end of address space) is the only one where wraparound would matter for pointers. And what would be the other option? If it's saturation, then your one-past-the-end pointer for the array at the end of address space would compare equal to pointer to last element...
- cbsmith 10y agoIt's pretty common to have stack and heap growing from opposite address ranges towards a central address space. That makes wrap around an unimportant feature that isn't worth the trouble. Now, runtimes are increasingly adopting address randomization, which can change the rules about this, depending on what you are doing.