Re: C and turtles, 80286 protected mode

On 16/10/2024 21:41, Scott Lurndal wrote:

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 10/15/24 9:08 PM, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C. I am not asking
if it is still in the std libraries, I am asking what happened
to make it impossible to write malloc() in std. C ?!?

>
It's easy enough to write malloc() in standard C if your flavor of the
standard includes a way to ask the operating system for heap space.
Back in the old days it was sbrk().  Now it's mmap(MAP_ANON).

>
Another possibility might be for the OS/hardware to support
allocate on use. This would be similar to an implicit
mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
would not be portable, but sbrk() and mmap() are not portable.

 The easiest way to implement malloc in standard C is to
start with a statically defined allocation region.
 e.g. malloc.c:
 ...
static unsigned char region[MAX_HEAP_IN_BYTES];
 void *
malloc(size_t size)
{
    /* manage heap and return allocation of size bytes */
}
 Downside is that the application always uses MAX_HEAP_IN_BYTES
plus the app size in memory; appropriate for standalone apps.
(traditional definition of standalone - no OS or other
runtime support).
 

There are other downsides to this.
One is that the "region" must be zeroed by the pre-main startup code. On some systems, there may be efficient ways to handle this, but on small embedded devices it usually means effectively memset'ing the heap before main() can start.  That can be a significant inconvenience for some systems.  C has (at the moment) no standard way to say that a variable does not need to be initialised, but there are usually implementation-specific ways to handle this.
The other issue is that returned memory blocks have a type - they are arrays of unsigned char - and when you use them for something else, your malloc'ed object aliases part of another normal C object (the array "region").  This can cause complications with advanced compiler analysis.