Re: 80286 protected mode

On 17/10/2024 05:06, George Neuner wrote:

On Wed, 16 Oct 2024 15:38:47 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
 

mitchalsup@aol.com (MitchAlsup1) writes:

On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote:
>

There is an advantage to the C approach of separating out some
facilities and supplying them only in the standard library.

>
It goes a bit further: for a general purpose language, any existing
functionality that cannot be written using the language is a sign of
a weakness because it shows that despite being "general purpose" it
fails to cover this specific "purpose".

>
One of the key ways C got into the minds of programmers was that
one could write stuff like printf() in C and NOT needd to have it
entirely built-into the language.
>

In an ideal world, it would be better if we could define `malloc` and
`memmove` efficiently in standard C, but at least they can be
implemented in non-standard C.

>
malloc() used to be std. K&R C--what dropped if from the std ??

>
It still is part of the ISO C standard.

>
The paragraaph with 3 >'s indicates malloc() cannot be written
in std. C. It used to be written in std. K&R C.

>
K&R may have been 'de facto' standard C, but not 'de jure'.
>
Unix V6 malloc used the 'brk' system call to allocate space
for the heap.   Later versions used 'sbrk'.
>
Those are both kernel system calls.

 Yes, but malloc() subdivides an already provided space.  Because that
space can be treated as a single array of char, and comparing pointers
to elements of the same array is legal, the only thing I can see that
prevents writing malloc() in standard C would be the need to somhow
define the array from the /language's/ POV (not the compiler's) prior
to using it.
 

It is common for malloc() implementations to ask the OS for large chunks of memory, then subdivide it and pass it out to the application.  When the chunk(s) it has run out, it will ask for more from the OS.  You could reasonably argue that each chunk it gets may be considered a single unsigned char array, but that is certainly not true for additional chunks.