Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: signal 10 in malloc call???
Keywords: sys V rel 3.1, died in malloc?
Message-ID: <11551@mimsy.UUCP>
Date: 18 May 88 11:33:32 GMT
References: <3989@killer.UUCP> <640@vsi.UUCP> <4016@killer.UUCP> <350@alice.marlow.reuters.co.uk>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

In article <350@alice.marlow.reuters.co.uk> fox@alice.marlow.reuters.co.uk
(Paul Fox) provides a simple checking version of malloc.  Note that
it assumes that one can store a single `long' in the address returned
by malloc, and increment the result by the size of that long, and that
the resulting pointer is still `well aligned'.  As far as I can tell
there is no way to avoid some similar assumption.  It might be nice
to have an include file with a macro or function that aligns a pointer:

	#include <align.h>
	...
		void *p, *q;
		q = align(p);
	/* or possibly better */
		void *p; int off;
		off = align_off(p);

where <align.h> might read

	#define align(p) ((void *)(((long)(p) + 3) & ~3))

for a machine with four-byte alignment, or

	#define align_off(p) ((8 - ((long)(p) & 7)) & 7)

for a machine with eight-byte alignment, and maybe even

	int align_off(void *p);

for a machine with wacky alignment constraints.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris