Path: ...!news.mixmin.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: Thu, 17 Oct 2024 16:25:01 +0200
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <ver6nt$2pcju$3@dont-email.me>
References: <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>
 <venqhc$241bk$3@dont-email.me> <prv0hj9belf10h7pjqpv00s35sqvc46puu@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 17 Oct 2024 16:25:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="32050b247ab65af6a4d716d6c5c97503";
	logging-data="2929278"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19vSsE4V3GbGk4LyvVWQasRJ023Yju/UVY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:eVicvcEUHzBrsuNidF3B2udGetk=
Content-Language: en-GB
In-Reply-To: <prv0hj9belf10h7pjqpv00s35sqvc46puu@4ax.com>
Bytes: 4369

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