David Edelsohn <dje....@gmail.com> writes: > This seems to be the core tension. If developers cared about these issues, > they would enable appropriate warnings and -Werror.
These issues are easy to miss and overlook. Making them louder helps prevent that. Additionally, requiring the users to remember a dozen flags to make the compiler strict rather than compatible is just terrible UX. Today, developers need to both care and know about toolchain oddities to effectively catch these errors, not just to care. > 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. Both the GNU Toolchain and the GNU Toolchain users will benefit from a stricter toolchain. People can and have stopped using the GNU Toolchain due to lackluster and non-strict defaults. This is certainly not positive for the brand, and I doubt it buys it much good will. Depending on what exactly you mean by package maintainers, there's already precedent on how to provide an out (and the OP talks about that exact topic, too, as it is not something to ignore). -- Arsen Arsenović
signature.asc
Description: PGP signature
