On Tue, May 9, 2023 at 5:28 PM David Edelsohn via Gcc wrote: > On Tue, May 9, 2023 at 4:40 PM Jonathan Wakely > wrote: > > > > > > > On Tue, 9 May 2023, 21:13 David Edelsohn, wrote: > > > >> On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc > >> wrote: > >> > >>> > Date: Tue, 9 May 2023 21:07:07 +0200 > >>> > From: Jakub Jelinek > >>> > Cc: Jonathan Wakely , arsen@aarsen.me, > >>> gcc@gcc.gnu.org > >>> > > >>> > On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc > wrote: > >>> > > > From: Jonathan Wakely > >>> > > > Date: Tue, 9 May 2023 18:15:59 +0100 > >>> > > > Cc: Arsen Arsenović , gcc@gcc.gnu.org > >>> > > > > >>> > > > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote: > >>> > > > > > >>> > > > > No one has yet explained why a warning about this is not > enough, > >>> and > >>> > > > > why it must be made an error. Florian's initial post doesn't > >>> explain > >>> > > > > that, and none of the followups did, although questions about > >>> whether > >>> > > > > a warning is not already sufficient were asked. > >>> > > > > > >>> > > > > That's a simple question, and unless answered with valid > >>> arguments, > >>> > > > > the proposal cannot make sense to me, at least. > >>> > > > > >>> > > > People ignore warnings. That's why the problems have gone unfixed > >>> for > >>> > > > so many years, and will continue to go unfixed if invalid code > >>> keeps > >>> > > > compiling. > >>> > > > >>> > > People who ignore warnings will use options that disable these new > >>> > > errors, exactly as they disable warnings. So we will end up not > >>> > > >>> > Some subset of them will surely do that. But I think most people > will > >>> just > >>> > fix the code when they see hard errors, rather than trying to work > >>> around > >>> > them. > >>> > >>> The same logic should work for warnings. That's why we have warnings, > >>> no? > >>> > >> > >> This seems to be the core tension. If developers cared about these > >> issues, they would enable appropriate warnings and -Werror. > >> > >> The code using these idioms is not safe and does create security > >> vulnerabilities. And software security is increasingly important. > >> > >> The concern is using the good will of the GNU Toolchain brand as the tip > >> of the spear or battering ram to motivate software packages to fix their > >> problems. It's using GCC as leverage in a manner that is difficult for > >> package maintainers to avoid. Maybe that's a necessary approach, but we > >> should be clear about the reasoning. Again, I'm not objecting, but > let's > >> clarify why we are choosing this approach. > >> > > > > 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. > > > > 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. > > > > I recently was discussing with a colleague that the C Language has been > rather conservative in its changes relative to other programming languages > with long histories. It probably has been somewhat constrained by the > existing Unix/Linux ecosystem and somewhat by C++ providing a C-adjacent > environment in which to experiment with more radical changes, not to > mention Objective-C, Objective-C++. > > Yes, memory safe languages have become the topic de rigueur. That > constituency probably only will be satisfied by gccrs, but we still should > try to improve GCC. The danger is developers who stop upgrading GCC and > who do not receive other bug fixes. > > We can make software security one of the driving principles of GCC and > state that explicitly. GCC needs a point of view. > Well said. I know over at RTEMS, we have been using GCC since before EGCS and during that time, we have upgraded our GCC version a lot of times. Often, the upgrade generates more warnings. We accept that as a benefit and cost of having a living project. We also may be on the more precise end of the scale in specifying our GCC arguments. We specify the language version, enable as many warnings as possible, etc. I think it is critical that a project pick their language version and ensure that they are not getting the default which shifts over time. We are currently using gcc 12 and specifying C11. To experiment with these stricter warnings and slowly address them, would we need to build with a newer C version? What practices might the GCC community recommend to a project wanting to discover the issues uncovered and slowly address them? I i am a bit gun shy because I remember the move from GCC 3.3 to 3.4 where the improved strict alias checking gave us a LOT of warnings to deal with and it felt overwhelming. I don't want to do that again. But I believe in letting the compiler get stricter and find things. Defaulting to stricter checking is a good thing. --joel sherrill RTEMS > > Thanks, David >