Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!ginosko!aplcen!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: ANSI C, hardware protection, out-of-bounds pointers
Message-ID: <19492@mimsy.UUCP>
Date: 9 Sep 89 05:21:28 GMT
References: <427@maytag.waterloo.edu> <1989Sep5.175411.25203@utzoo.uucp> <9520@chinet.chi.il.us>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

In article <9520@chinet.chi.il.us> kdb@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@mimsy.umd.edu	Path:	uunet!mimsy!chris