Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c,net.lang.c++
Subject: Re: oops, corrupted memory again!
Message-ID: <763@bentley.UUCP>
Date: Sun, 27-Apr-86 15:27:12 EDT
Article-I.D.: bentley.763
Posted: Sun Apr 27 15:27:12 1986
Date-Received: Tue, 29-Apr-86 00:43:44 EDT
References: <4495@cbrma.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 21
Xref: watmath net.lang.c:8752 net.lang.c++:172

In article <4495@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