Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <86y12uy8ku.fsf@linuxsc.com> <3f2cb127c8d5dc2381fc80631a495e3e@www.novabbs.org> 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: Bytes: 4369 On 17/10/2024 05:32, George Neuner wrote: > On Wed, 16 Oct 2024 09:38:20 +0200, David Brown > 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? >>