Bryan Donlan said:
Alexei A. Frounze wrote: ....
On the contrary, it is very likely to cause the system to crash or some kind
of malloc asserts to be tripped. It's common to have some sort of pointer
immediately before a mallocced memory block, or at least a size indicator.
The system will only crash if the user memory manager is dumb and there's no
memory protection employed in the CPU. On x86 the system (windows or linux)
won't crash if the user app does something like free(ip+2). On such a
system, the maximum problem that one may get is an exception and maybe
program termination.
As for the user memory manager (or libc's malloc/free), some sanity checks
are due anyway. The mm must check whether the pointer falls inside the range
of the address space where the memory is managed, whether the pointer points
to a beginning of a valid and allocated block. It shouldn't be very hard to
perform these checks. Even if an implementation of the mm does not catch all
100% of mm-related problems, many of them will be caught. If the control
information cannot be protected from the damage, some CRC-aided cheks will
help at least determine whether or not the control info is still valid.
If someone tells this would degrade the performance I'd agree, but then
again, a question naturally arises... Is the algorithm picked in the app
good enough at all if it's too dependent on the mm speed?
If we assume dumb programmers and their apps (actually, that should be
assumed as even experienced and good programmers sometimes do bad things,
most often accidentally and not because they didn't know something), we must
provide more or less stable and error-detecting basis for them, i.e. the
standard libraries, etc.
Alex