malloc impossible? (was: inkey$, noecho, and other impossibles)

[Chris Torek]

>In article <15406 at mimsy.UUCP> chris at 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).

In article <9342 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
[malloc example deleted]
>Such an implementation of malloc() must work if the C language works.

Sure---by definition of `the C language'.

>That's why I claim that malloc() is implementable on all architectures
>for which an implementation of C is feasible.

But I claim that, if the requirement for malloc() were dropped, one
could implement C-minus-malloc on a machine that (say) required all
floating point numbers to live in the floating-point address space,
by having two stacks (one in the integer space and one in the fp space)
and two data segments (likewise).  The point is that it also needs
two heaps, and the single argument one provides to malloc() does not
provide the information necessary to decide which heap to use:

	void *
	weird_machine_malloc(size_t size, enum Space_selector space) {
		static char intspacepool[INTSIZE];
		static float floatspacepool[FLOATSIZE];
		static size_t intfree = INTSIZE;
		static size_t floatfree = FLOATSIZE;

		if (space == Space_float) {
			if (size % (sizeof(float)-1) || size > floatfree)
				return NULL;	/* bad size */
			... allocate from floatspacepool ...
		} else {
			... allocate from intspacepool ...
		}
	}

One can imagine a machine with different spaces for each different
intrinstic data type, where malloc() has to select from one of 8
or 16 possibilities.  Of course, since malloc() gets only one argument,
it has no way to decide which address space to use.
-- 
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