Re: 80286 protected mode

(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