Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Thu, 17 Oct 2024 02:48:49 -0700
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <86y12nvz3y.fsf@linuxsc.com>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <memo.20241006163428.19028W@jgd.cix.co.uk> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <ve5ek3$2jamt$1@dont-email.me> <be506ccef76d682d13205c69c761a086@www.novabbs.org> <ve6oiq$2pag3$1@dont-email.me> <ve6tv7$2q6d5$1@dont-email.me> <86y12uy8ku.fsf@linuxsc.com> <jwv34kx5afd.fsf-monnier+comp.arch@gnu.org> <3f2cb127c8d5dc2381fc80631a495e3e@www.novabbs.org> <8HBPO.471560$_o_3.464389@fx17.iad> <d8cffb389b3fd055ee70e87da9a3403a@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 17 Oct 2024 11:48:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4d902cc0473bdb0fc4a91596ca166507";
	logging-data="2853073"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/FX+2vjB3vRaYP+aUz+gnnqSO/7+nkJSM="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:BjLkiVniL8kwOnO4OA42zyLDOIo=
	sha1:q6ZakFGMJWtI/rzmSMXTtmLFDyw=
Bytes: 4672

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 need 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 standard K&R C--what dropped if from the
>>> standard??
>>
>> It still is part of the ISO C standard.
>
> The paragraph with 3 >'s indicates malloc() cannot be written in
> standard C.  It used to be written in standard K&R C.

No, it didn't.  In the original book (my copy is from the third
printing of the first edition, copyright 1978), on page 175 there
is a function 'alloc()' that shows how to write a memory allocator.
The code in alloc() calls 'morecore()', described as follows:

   The function morecore obtains storage from the operating system.
   The details of how this is done of course vary from system to
   system.  In UNIX, the system entry sbrk() returns a pointer to n
   more bytes of storage.  [...]

An implementation of morecore() is shown on the next page, and
it indeed uses sbrk() to get more memory.  That makes it UNIX
specific, not portable standard C.  Both alloc() and morecore()
are part of chapter 8, "The UNIX System Interface".

Note also that chapter 7, titled "Input and Output" and describing
the standard library, mentions in section 7.9, "Some Miscellaneous
Functions", the function calloc() as part of the standard library.
(There is no mention of malloc().)  The point of having a standard
library is that the functions it contains depend on details of the
underlying OS and thus cannot be written in platform-agnostic code.
Being platform portable is the defining property of "standard C".

(Amusing aside: the entire standard library seems to be covered by
just #include <stdio.h>.)

> I am not
> asking if it is still in the standard libraries, I am asking what
> happened to make it impossible to write malloc() in standard C ?!?

Functions such as sbrk() are not part of the C language.  Whether
it's called calloc() or malloc(), memory allocation has always
needed access to some facilities not provided by the C language
itself.  The function malloc() is not any more writable in standard
K&R C than it is in standard ISO C (except of course malloc() can
be implemented by using calloc() internally, but that depends on
calloc() being part of the standard library).