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 1A1D63856DD6 for ; Wed, 10 May 2023 13:30:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A1D63856DD6 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 1pwjtT-0005jA-KD for gcc@gcc.gnu.org; Wed, 10 May 2023 15:30:11 +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 15:30:02 +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> <83zg6c8lju.fsf@gnu.org> <83r0ro8jgv.fsf@gnu.org> 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: <83r0ro8jgv.fsf@gnu.org> X-Spam-Status: No, score=-1.7 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=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 14:22, Eli Zaretskii via Gcc wrote: >> From: Jonathan Wakely >> Date: Wed, 10 May 2023 12:49:52 +0100 >> Cc: David Brown , gcc@gcc.gnu.org >> >>> If some developers want to ignore warnings, it is not the business of >>> GCC to improve them, even if you are right in assuming that they will >>> not work around errors like they work around warnings (and I'm not at >>> all sure you are right in that assumption). But by _forcing_ these >>> errors on _everyone_, GCC will in effect punish those developers who >>> have good reasons for not changing the code. What would those "good reasons" be, in your opinion? (I realise I am asking you to be speculative and generalise. This discussion is an exchange of opinions, thoughts, experiences and impressions.) Frankly, the most common "good" reason for a developer not changing their code from pre-C99 is that they retired long ago. And people should definitely question whether the code should be kept. As I noted in another post, it is entirely reasonable to suspect that such old code has errors - unwarranted assumptions that were considered appropriate back in the days when such code techniques were considered appropriate. It has always been the unfortunate case with C programming that getting optimal results for some compilers has sometimes involved "cheating" a bit, such as assuming wrapping signed arithmetic or converting pointer types and breaking the "strict aliasing" rules. Changing the gcc defaults and requiring old code to use flags that allow old constructs but limiting optimisations is not /punishing/ the old code or its developers or maintainers. It is /supporting/ it - allowing it to be used more safely with modern tools. On the other hand, continuing to accept old, outdated code by lax defaults is punishing /current/ developers and users. Why should 99.99% of current developers have to enable extra errors to catch mistakes (and we all make occasional mistakes in our coding - so they /should/ be enabling these error flags)? Why should they have to deal with other people's code that was badly written 30 years ago? Is it really worth it, just so that a half-dozen maintainers at Linux distributions can recompile the 40-year old source for "ed" without adding a flag to the makefile? Ultimately, /someone/ is going to suffer - a compiler can't have good defaults for current developers and simultaneously good defaults for ancient relics. The question to consider is not whether we "punish" someone, but /whom/ do we punish, and what is the best balance overall going forward. >> >> There will be options you can use to continue compiling the code >> without changing it. You haven't given a good reason why it's OK for >> one group of developers to have to use options to get their desired >> behaviour from GCC, but completely unacceptable for a different group >> to have to use options to get their desired behaviour. >> >> This is just a change in defaults. > > A change in defaults that is not backward-compatible should only be > done for very good reasons, because it breaks something that was > working for years. No such good reasons were provided. I'm sorry, but I believe I /did/ provide good reasons. Granted, they were in more than one post. And many others here have also given many good reasons. At the very least, making a safer and more useful compiler that helps developers make better code is a good reason, as is making a C compiler that is closer to standards compatibility by default. I do agree that backwards compatibility breaks should only be done for good reasons. But I think the reasons are good. > And no, > educating/forcing GCC users to use more modern dialect of C is not a > good reason. > Yes, it /is/ a good reason. But I suppose that one is a matter of opinion. I encourage you to look at CERT/CC, or other lists of code errors leading to security issues or functional failures. When someone writes poor code, lots of people suffer. Any initiative that reduces the likelihood of such errors getting into the wild is not just good for gcc and its users, it's good for the whole society. Consider why Rust has become the modern fad in programming. People claim it is because it is inherently safer than C and C++. It is not. There are really two reasons for it appearing to be safer. One is that the /defaults/ for the tools, and the language idioms, are safer than the /defaults/ for C and C++ tools. That makes it harder to make mistakes. The other is that it has no legacy of decades of old code and old habits, and no newbie programmers copying those old styles. Rust code is written in modern development styles, with a care for correctness rather than getting maximum efficiency from limited old-fashioned tools or macho programming. The only reason there is any sense in re-writing old programs in Rust is because re-writing them in good, clear, modern C (or C++) is never going to happen - even though the results would be as safe or safer. So yes, anything that pushes C programmers into being better C programmers is worth considering, IMHO. We will never stamp out bad programming, but we can try to help them - giving them better tools that help them spot problems early is a step forward. >> Accepting broken code by default is not a priori a good thing, as >> you seem to insist. Rejecting it by default is not a priori a good >> thing. There is a pragmatic choice to be made, and your argument is >> still no more than "it compiles today, so it should compile >> tomorrow". > > Once again: it isn't "broken code". It is dangerous code, and in some > cases unintentionally suspicious code. But it isn't broken, because > GCC can compile it into a valid program, which, if the programmer > indeed meant that, will work and do its job. > Sweeping problems under the carpet and hoping no one trips over the bumps is, at best, pushing problems down the road for future developers. Remember, when people wrote that old code, they didn't know the future of C, of compilers, of computers. Maybe the code was not broken at the time, but times have changed. >>>> Agreed. But if we can make it harder for them to release bad code, >>>> that's good overall. >>> >>> I'm okay with making it harder, but without making it too hard for >>> those whose reasons for not changing the code are perfectly valid. >>> This proposal crosses that line, IMNSHO. >> >> Where "too hard" means using a compiler option. Seriously? This seems farcical. > > This goes both ways, of course. GCC had -Werror since about forever. >