Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Wed, 16 Oct 2024 19:57:03 +0200
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <veoupf$2b2ul$1@dont-email.me>
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>
 <venpin$241bk$2@dont-email.me> <jwvldyo3x1h.fsf-monnier+comp.arch@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 16 Oct 2024 19:57:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="275fdeb4ba0a4c3eef30b2089041785d";
	logging-data="2460629"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19GErHJEJt90lO6guWDwO6Dl0GMsFyUgFk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:3iLs5GPf/EYnWVVyTNKuenHGJBo=
In-Reply-To: <jwvldyo3x1h.fsf-monnier+comp.arch@gnu.org>
Content-Language: en-GB
Bytes: 5163

(Please do not snip or omit attributions.  There are Usenet standards 
for a reason.)

On 16/10/2024 17:18, 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".
>>> 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.
>> I don't see an advantage in being able to implement them in standard C.
> 
> It means you can likely also implement a related yet different API
> without having your code "demoted" to non-standard.

That makes no sense to me.  We are talking about implementing standard 
library functions.  If you want to implement other functions, go ahead.

Or do you mean that it is only possible to implement related functions 
(such as memory pools) if you also can implement malloc in fully 
portable standard C?  That would make a little more sense if it were 
true, but it is not.  First, you can implement such functions in 
implementation-specific code, so you are not hindered from writing the 
code you want.  Secondly, standard C provides functions such as malloc() 
and aligned_alloc() that give you the parts you need - the fact that you 
need something outside of standard C to implement malloc() does not 
imply that you need those same features to implement your additional 
functions.

> E.g. say if your application wants to use a region/pool/zone-based
> memory management.
> 
> The fact that malloc can't be implemented in standard C is evidence
> that standard C may not be general-purpose enough to accommodate an
> application that wants to use a custom-designed allocator.
> 

No, it is not - see above.

And remember how C was designed and how it was intended to be used.  The 
aim was to be able to write portable code that could be reused on many 
systems, and /also/ implementation, OS and target specific code for 
maximum efficiency, systems programming, and other non-portable work.  A 
typical C program combines these - some parts can be fully portable, 
other parts are partially portable (such as to any POSIX system, or 
targets with 32-bit int and 8-bit char), and some parts may be very 
compiler-specific or target specific.

That's not an indication of failure of C for general-purpose 
programming.  (But I would certainly not suggest that C is the best 
choice of language for many "general" programming tasks.)

> I don't disagree with you, from a practical perspective:
> 
> - in practice, C serves us well for Emacs's GC, even though that can't
>    be written in standard C.
> - it's not like there are lots of other languages out there that offer
>    you portability together with the ability to define your own `malloc`.
> 
> But it's still a weakness, just a fairly minor one.
> 
>> The reason why you might want your own special memmove, or your own special
>> malloc, is that you are doing niche and specialised software.
> 
> Region/pool/zone-based memory management is common enough that I would
> not call it "niche", FWIW, and it's also used in applications that do want
> portability (GCC and Apache come to mind).
> Can't think of a practical reason to implement my own `memove`, OTOH.
> 
> 
>          Stefan