oops, corrupted memory again!

KW Heuer kwh at bentley.UUCP
Mon Apr 28 05:27:12 AEST 1986


In article <4495 at cbrma.UUCP> cbrma!trl (Tom Lanning) writes:
>	Are there any "malloc" routines that check for modification of
>malloc's link pointers by the "user's" code?   Close to 70% of by bugs
>are stack/memory problems were I use more space than I allocated.

As mentioned in the man page, the malloc() code has a compile-time option
for strict checks on the arena.  (This is not too useful if you have no
source code, of course.)

In C++, you can define a datatype that works like a pointer but does
run-time bounds checking; this requires changing your declarations from
"char *" to "vector" (or whatever).

Now, if only somebody would invent an architecture where all objects,
including dynamicly allocated objects, are isolated in memory, then any
subscript error would cause an immediate memory fault.  You'd still be
vulnerable to completely wild pointers (but less likely in a huge address
space), and overflow of an array inside a structure might be untrappable,
but otherwise it sounds like a great machine to do your debugging on.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint



More information about the Comp.lang.c mailing list