From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 0E8FC3873E67 for ; Wed, 10 May 2023 14:21:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E8FC3873E67 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pwkga-0002jS-Vj for gcc@gcc.gnu.org; Wed, 10 May 2023 16:20:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc@gcc.gnu.org From: David Brown Subject: Re: More C type errors by default for GCC 14 Date: Wed, 10 May 2023 16:20:49 +0200 Message-ID: References: <022d06d7-a61a-bbdb-cea1-021af4ccf489@starynkevitch.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-GB In-Reply-To: <022d06d7-a61a-bbdb-cea1-021af4ccf489@starynkevitch.net> X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_40,FORGED_MUA_MOZILLA,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/05/2023 15:10, Basile Starynkevitch wrote: > Hello all, > > After a suggestion by Eric Gallager >> Idea for a compromise: What if, instead of flipping the switch on all >> 3 of these at once, we staggered them so that each one becomes a >> default in a separate release? i.e., something like: >> >> - GCC 14: -Werror=implicit-function-declaration gets added to the >> defaults >> - GCC 15: -Werror=implicit-int gets added to the defaults >> - GCC 16: -Werror=int-conversion gets added to the defaults >> >> That would give people more time to catch up on a particular warning, >> rather than overwhelming them with a whole bunch all at once. Just an >> idea. > > Eli Zaretskii wrote on 10 may 2023, at 14:00 > >> And that is just one example of perfectly valid reasons for not >> wanting or not being able to make changes to pacify GCC. >> >> Once again, my bother is not about "villains" who don't want to get >> their act together, my bother is about cases such as the one above, >> where the developers simply have no practical choice. >> >> And please don't tell me they should use an older GCC, because as >> systems go forward and are upgraded, older GCC will not work anymore. > > > My experience is that for safety critical software (per DOI 178C, > embedded in aircrafts, or for the French covid breathing machine on > https://github.com/Recovid/Controller ) the regulations, funders, and > authorities requires a very specific version of GCC with very specific > compilation flags. > > > Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the > compilation flags (even changing -O1 by -O2) requires written (on paper) > approval by a large number of human persons, and formal certifications > (eg ISO9001, ISO27001 procedures) and lots of checks and headaches. > > > I do know several persons making their living of these constraints. > > I do know several corporations making a living from them (and keeping > decade older GCC compiler binaries on many disks). > > So I really think that for safety critical software (whose failure may > impact lives) people are using an older (and well specified) GCC. > > > Of course, to compile an ordinary business web service (e-shop for > clothes) with e.g. libonion (from https://github.com/davidmoreno/onion > ...) or to compile a zsh.org from source code (for or on a developer's > laptop) the constraints are a lot lighter. > > Regards! > In my line of work (small-systems embedded programming), the source for a program does not just include the C source code. It includes the build system, compiler version, the flags used, and the library used - everything that can affect the resulting binary. I realise I am far more paranoid about that kind of thing than the majority of developers, but it is also noteworthy that there is a trend towards reproducible builds in more mainstream development. The oldest gcc I have on my machine is 2.95.3 for the 68k, from 1998. I have some older compilers, but they are not gcc. I wouldn't say I made a living out of this, but I have had a customer who was very happy that I could make a fix in a program I wrote 20 years previously, and could compile it with exactly the same tools as I used then. One of the reasons I use gcc (in a world where companies are willing to pay $5000 for tools from the likes of Green Hills) is that I can keep the old versions around, and copy and use them at will. And for those that are more demanding than me, they can of course archive the sources for gcc (and other parts of the toolchain). Those that /really/ need old versions of the toolchain, can use old versions of the toolchain. And if gcc 14 changes in such a way that distro maintainers can't use it to build ancient packages, then they should make gcc-13 a part of their base packages as well as current gcc, and ship gcc version 13 for as long as they ship "ed", "rn" and other software from the middle ages.