ANSI C, hardware protection, out-of-bounds pointers

[Chris Torek]

In article <9520 at chinet.chi.il.us> kdb at chinet.chi.il.us (Karl Botts) writes:
>The following is in no way guaranteed by ANSI C, but I think it something
>you can depend on pretty solidly.  Any standard implementation of malloc()
>et al. puts either the size of the block or a pointer to the next block in
>the machine word just before the start of the block; this will be in the
>same linear address space.  Thus you can be sure that mentioning this word
>(or even dereferencing it) will not cause an exception.  Of course this
>only holds true for malloc()ed blocks.

This assumption is inadvisable.  Future Unix versions are quite likely
to have better/faster/fancier malloc()s that hide sizes elsewhere.
Putting pointers and sizes at the front of blocks is, for instance,
bad for paging.

As a nice side effect, when the implementation puts malloc() information
outside the blocks allocated, it can (a) arrange for the system to
leave `holes' in the address space at the edges of each block (this
traps many off-the-end references, though not all), and (b) arrange
for runtime checking to make sure you have not written over the ends
of allocated storage.

A malloc that finds code like

	p = malloc(strlen(s));
	if (p == NULL) die();
	strcpy(p, s);

can be quite helpful.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris