A tale of two C's.

[ECSC68 S Brown CS]

In article <195 at sdeggo.UUCP> dave at sdeggo.UUCP (David L. Smith) writes:
>>In article <7750 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>
>The one that I have seen most commonly is a replacement malloc() 
>routine.  For example, the Bourne shell replaces malloc() with its 
>own version so that it can have a stack interspersed with the heap.
>
>Whether or not this was necessary I'm not sure, but it does seem 
>like the easiest way to implement it.  The stack is set at the top 
>of memory; when it grows to big it generates a segmentation violation 
>which causes malloc() to allocate more memory and relocate the stack 
>at the top of memory.  The other alternative, if implemented with 
>vanilla malloc, would be to give some memory to the stack and then 
>monitor it everytime something was put on the stack to make sure it 
>didn't overflow.  Relying on the system to tell you when you're
>out of space is a lot easier.
>

This "relying on the system" technique isn't really the main reason why
sh has it's own malloc - after all, on 68000-based systems, growing-on-sigsegv
doesn't work anyway, but sh still needs it's own malloc there. The real
reason for it is that it provides the possibility of "open-ended" malloc'ing,
where you don't know how much space is required at the time when you call
malloc. For example,
	p = q = open_ended_malloc();
	while (something())
		*q++ = blob();
	close_malloc(q);
will give you a pointer "p" pointing to everything you put on, up to the call
of close_malloc(). It certainly beats having to do it all with unpleasant
linked-lists all the time. I'm surprised no other programs use this technique,
it seems so useful!

	Simon.

-- 
--------------------------------------------------
| Simon Brown                                    |
| Laboratory for Foundations of Computer Science |
| Department of Computer Science                 |
| University of Edinburgh, Scotland, UK.         |
--------------------------------------------------
 UUCP:  uunet!mcvax!ukc!lfcs!simon
 ARPA:  simon%lfcs.ed at nss.cs.ucl.ac.uk
 JANET: simon at uk.ac.ed.lfcs