I recently finished reading about virtual memory and I have a question about how malloc works within the Virtual address space and Physical Memory.
For example (cod
It's undefined behaviour...
if you try to access outside bounds anything may happen, including SIGEGV or corruption elsewhere in the stack that causes your program to produce wrong results, hang, crash later etc..
the memory may be writable without obvious failure on some given run for some compiler/flags/OS/day-of-the-week etc. because:
malloc() might actually allocate a larger sized allocated block wherein [500] can be written to (but on another run of the program, might not), or[500] might be after the allocated block, but still memory accessible to the program
[500] - being a relatively small increment - would still be in the heap, which might extend beyond further than the addresses that malloc calls have so-far yielded due to some earlier reservation of heap memory (e.g. using sbrk()) in preparation for anticipated use[500] is "off the end of" the heap, and you end up writing to some other memory area, where e.g. over static data, thread-specific data (including the stack)Why it this allowed to happen?
There's two aspects to this:
checking indices on every access would bloat (add extra machine code instructions) and slow down execution of the program, and generally the programmer can do some minimal validation of indices (e.g. validating once when a function's entered, then using the index however-many times), or generate the indices in a way that guarantees their validity (e.g. looping from 0 to the array size)
managing the memory extremely precisely, such that out-of-bounds access is reported by some CPU fault, is highly dependent on hardware and in general only possible at page boundaries (e.g. granularity in the 1k to 4k range), as well as taking extra instruction (whether within some enhanced malloc function or in some malloc-wrapping code) and time to orchestrate.