Path: ...!news.mixmin.net!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 00:40:34 -0700
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <868qunxjm5.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> <vep60r$2ck8s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 17 Oct 2024 09:40:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4d902cc0473bdb0fc4a91596ca166507";
	logging-data="2804326"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zpJ+AtFgWWNSQFSVpp2IeenDisN10ado="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:736kBcSQd9ZIAxWAQH7AHX9oRic=
	sha1:ExsJGhF7J1iAkbxXaKSGy5qQejw=
Bytes: 2844

Thomas Koenig <tkoenig@netcologne.de> writes:

> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>
>> 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 ?!?
>
> You need to reserve memory by some way from the operating system,
> which is, by necessity, outside of the scope of C (via brk(),
> GETMAIN, mmap() or whatever).

Right.  And that is why malloc(), or some essential internal component
of malloc(), has to be platform specific, and thus malloc() must be
supplied by the implementation (which means both the compiler and the
standard library).

> But more problematic is the implementation of free() without knowing
> how to compare pointers.

Once there is a way to get additional memory from whatever underlying
environment is there, malloc() and free() can be implemented (and I
believe most often are implemented) without needing to compare
pointers.  Note:  pointers can be tested for equality without having
to compare them relationally, and testing pointers for equality is
well-defined between any two pointers (which may need to be converted
to 'void *' to avoid a type mismatch).