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 5BB183858414 for ; Thu, 11 May 2023 07:59:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5BB183858414 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 1px1Cr-0007We-At for gcc@gcc.gnu.org; Thu, 11 May 2023 09:59:21 +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: Thu, 11 May 2023 09:59:15 +0200 Message-ID: References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <87zg6bei0v.fsf@yahoo.com> 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: <87zg6bei0v.fsf@yahoo.com> X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,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=no 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 11/05/2023 04:09, Po Lu via Gcc wrote: > jwakely.gcc@gmail.com (Jonathan Wakely) writes: > >> So let's do it. Let's write a statement saying that the GCC developers >> consider software security to be of increasing importance, and that we >> consider it irresponsible to default to accepting invalid constructs in the >> name of backwards compatibility. State that we will make some changes which >> were a break from GCC's traditional stance, for the good of the ecosystem. > > I'm sorry you think that way. > >> Given recent pushes to discourage or outright ban the use of memory-safe >> languages in some domains, I think it would be good to make a strong >> statement about taking the topic seriously. And not just make a statement, >> but take action too. >> >> If we don't do this, I believe it will harm GCC in the long run. The vocal >> minority who want to preserve the C they're used to, like some kind of >> historical reenactment society, would get their wish: it would become a >> historical dead end and go nowhere. > > Vocal minority? Do you have any evidence to back this claim? > > What I see is that some reasonable organizations have already chosen > other C compilers which are capable of supporting their existing large > bodies of C code that have seen significant investment over many years, > while others have chosen to revise their C code with each major change > to the language. > > The organizations which did not wish to change their code did not > vocally demand changes to GCC after GCC became unsuitable, but quietly > arranged to license other compilers. > > Those that continue write traditional C code know what they are doing, > and the limitations of traditional C do not affect the quality of their > code. For example, on the Unix systems at my organization, the SGS is > modified so that it will not link functions called through a declaration > with no parameter specification with a different set of parameters than > it was defined with. > > Naturally, the modified linker is not used to run configure scripts. > Let's be absolutely clear here - gcc has been, and will continue to be, able to compile code according to old and new standards. It can handle K&R C, right through to the cutting edge of newest C and C++ standards. It can handle semantic requirements such as two's complement wrapping and "anything goes" pointer type conversions - features that a lot of old code relies on but which are not documented or guaranteed behaviour for the vast majority of other compilers. It can handle all these things - /if/ you pick the correct flags. With the proposed changes, you can still compile old K&R code with gcc - if you give it the right flags. No features are being removed - only the default flags are being changed. If anyone is changing from gcc to other compilers because they think newer gcc does not support older code, then they are perhaps doing so from ignorance. If some users are willing to change to different compilers, but unwilling to learn or use new flags in order to continue using their existing compiler after it changes its defaults, then perhaps gcc could pick different defaults depending on the name used for the executable? If it is invoked with the name "gcc-kr", then it could accept K&R code by default and have "-std=gnu90" (I believe that's the oldest standard option). If it is invoked as "gcc", then it would reject missing function declarations, implicit int, etc., as hard errors. Then these users could continue to use gcc, and their "new" compiler to handle their old code would be nothing more than a symbolic link. David