From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 7AE9B385702F for ; Wed, 10 May 2023 14:38:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7AE9B385702F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TjqkHo4dhHlbS44Z+pLSz+P/azd4RgloZqGMiwn9Tnc=; b=JNlToWrB8dMj SR4SZcxtvKwhUn1n5ZOWmB/hVyqvQqQMQFeBnGyfgz7zvCIBWCtOd4jmif2JTwG98ZUL/0cUpqZI9 ybC3dTW6kdzSAlPTJ9iuubWcvHFXIcHYSHzRcPuCwaYTOm09TYHCxIphBr2vWIpA/nxuNttmz2A1D YIrNJpTMlhzFi4GcWZ2JRMJa6K1DOlGBZ0opErChP5fNPlfu45oKP/Qo6UJ53MunTILhMNuzaRufZ 35/wy+ZSMfgV0wL1VXsNI9Zu/KCPZFwAp2WmeMnABo8l0me6YI8NmfOv+x2OYU/wDPPM7RngdAgUW +zAJ/WJu3gy2y5F4I6dRAg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwkxn-0006Lu-U4; Wed, 10 May 2023 10:38:44 -0400 Date: Wed, 10 May 2023 17:39:49 +0300 Message-Id: <831qjo8d3e.fsf@gnu.org> From: Eli Zaretskii To: David Brown Cc: gcc@gcc.gnu.org In-Reply-To: (message from David Brown via Gcc on Wed, 10 May 2023 15:30:02 +0200) Subject: Re: More C type errors by default for GCC 14 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> X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Wed, 10 May 2023 15:30:02 +0200 > From: David Brown via Gcc > > >>> 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? For example, something that adversely affects GCC itself and its ability to compile valid programs. > 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)? Adding a flag to a Makefile is infinitely easier than fixing old sources in a way that they produce the same machine code. > I do agree that backwards compatibility breaks should only be done for > good reasons. But I think the reasons are good. Not good enough, not for such a radical shift in the balance between the two groups. > > And no, > > educating/forcing GCC users to use more modern dialect of C is not a > > good reason. > > > > Yes, it /is/ a good reason. Not for a compiler. A compiler is a tool, it is none of its business to teach me what is and what isn't a good dialect in each particular case. Hinting on that, via warnings, is sufficient and perfectly okay, but _forcing_ me is not. > 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. Exactly. We cannot reasonably expect that a compiler which needs to support 50 years of legacy code to be as safe as a compiler for a language invented yesterday afternoon. People who want a safe programming environment should not choose C as their first choice. > 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. I agree, I'm just saying that warnings are helpful enough -- for those who want to be helped. > > 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. I'm not sweeping anything. This is not GCC's problem to solve, that's all. If the developer avoids dealing with this problem, then he or she might be sweeping the problem under the carpet. But this is not GCC's problem.