Path: utzoo!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: malloc impossible? (was: inkey$, noecho, and other impossibles)
Message-ID: <9342@smoke.BRL.MIL>
Date: 12 Jan 89 05:08:29 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <9338@smoke.BRL.MIL> <15406@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <15406@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Actually, I was thinking about machines in which different types
>of objects must come from different address spaces (e.g., all
>`pointer' objects should be in the range 0x70000000..0x7c000000).

I still don't understand your example.  If C is to be implemented
on any architecture, the implementor has to arrange for pointers
to data objects to have the right properties, independently of
whether malloc looks something like:
	#define POOLMAX 10000
	static char pool[POOLMAX];
	static char *next = pool;
	void *malloc(size_t n) {
		register char *p;
		if (next - pool > POOLMAX - n)
			return NULL;
		p = next;
		next += n;	/* assume byte alignment is ok */
		return (void *)p;
	}
(Note -- I realize this is not a GOOD way to implement malloc, but
it is a POSSIBLE way, suitable for purposes of this discussion.
Naturally, one should implement malloc() better than this if at all
possible.)

Such an implementation of malloc() must work if the C language works.
That's why I claim that malloc() is implementable on all architectures
for which an implementation of C is feasible.