Re: 80286 protected mode

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

On Wed, 16 Oct 2024 09:38:20 +0200, David Brown
<david.brown@hesbynett.no> wrote:
 

It's a very good philosophy in programming language design that the core
language should only contain what it has to contain - if a desired
feature can be put in a library and be equally efficient and convenient
to use, then it should be in the standard library, not the core
language.  It is much easier to develop, implement, enhance, adapt, and
otherwise change things in libraries than the core language.
>
And it is also fine, IMHO, that some things in the standard library need
non-standard C - the standard library is part of the implementation.

 But it is a problem if the library has to be written using a different
compiler.  [For this purpose I would consider specifying different
compiler flags to be using a different compiler.]

Specifying different flags would technically give you a different /implementation/, but it would not normally be considered a different /compiler/.  I see no problem at all if libraries (standard library or otherwise) are compiled with different flags.  I can absolutely guarantee that the flags I use for compiling my application code are not the same as those used for compiling the static libraries that came with my toolchains.  Using different /compilers/ could be a significant inconvenience, and might mean you lose additional features (such as link-time optimisation), but as long as the ABI is consistent then they should work fine.

 Why?  Because once these things are discovered, many programmers will
see their advantages and lack the discipline to avoid using them for
more general application work.
 

Really?  Have you ever looked at the source code for a library such as glibc or newlib?  Most developers would look at that and quickly shy away from all the macros, additional compiler-specific attributes, conditional compilation, and the rest of it.  Very, very few would look into the details to see if there are any "tricks" or "secret" compiler extensions they can copy.  And with very few exceptions, all the compiler-specific features will already be documented and available to programmers enthusiastic enough to RTFM.

 

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 ??

>
The function has always been available in C since the language was
standardised, and AFAIK it was in K&R C.  But no one (in authority) ever
claimed it could be implemented purely in standard C.  What do you think
has changed?
>