On Tue, 09 May 2023 16:07:50 +0100 Sam James via Gcc <gcc@gcc.gnu.org> wrote:
> Florian did note this already - ABI. Implicit function declarations are > pretty horrible in a number of cases: > - they prevent fortification (_FORTIFY_SOURCE) So what? Print a warning, for those who are writing new code or maintaining old code and actually care. Done. > - they prevent time64 and LFS migrations from working correctly So what? Print a warning, for those who are writing new code or maintaining old code and actually care. Done. 2038 is 15 years away. I'm trying to keep existing code working TODAY. > - they break with different ABIs (see e.g. Apple's arm64 ABI) I don't care about Apple or ARM64. I'm trying to keep old code working fine on x86. > - they can cause runtime crashes when combined wtih bfd's default of > not warning on underlinking My system is perfectly stable, thanks. In fact it is much more stable and much snappier than the garbage released by the likes of Fedora, RedHat, etc. If runtime crashes and stability were a concern for those folks, they should start by dropping 'Linux Puttering' out of a helicopter. > int-conversion generally indicates severe runtime problems as well. Not in my experience. My system works fine, despite approximately 10,000,000 warnings spit out by GCC during the build process. > Many of the cases I've seen on musl absolutely do not work at runtime and > weren't caught by any other warnings (often because of padding mismatches). Well that's the risk you take by changing the C standard library. My system works fine on glibc. If any given package has a problem on musl, I will take that on a case by case basis. Wrecking my build process by introducing 10,000 new errors isn't part of the solution. > That's why Fedora and Gentoo have been aggressively working on this > before even proposing it. We are being proactive in making sure that > common things are fixed. Yeah, you're being proactive in ruining everything. Thanks. How's systemd and pulseaudio working out for you? > I don't know if it's that aggressive to drop something which was > removed in C99 because of how dangerous it is. You're breaking old code unnecessarily by introducing an error, when the existing warning is perfectly fine. If it was such a horrible, terrible, no-good thing that it must be removed immediately, then why wasn't this already changed decades ago? Hint: BECAUSE YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON. > Also, keep in mind, Florian went around and asked many of the first > group (the foundational folks) who didn't object. No, he asked a few big shot million dollar well-funded distributions if they had any problems with increasing their workload and maybe hiring a few extra developers. Unsurprisingly that select group of insiders had no problem with it. Meanwhile there are thousands of other smaller users and organizations out there whose concerns are just as important. > Not that this is a strong argument, and I don't like making it, but > if Clang is doing it and GCC does too, it's not like they can reassess > their choices anyway. In fact that's exactly why GCC should continue just the way it is, so that people can have an actual alternative to the "bondage and discipline" approach, and continue keeping their old code working just fine when there are literally NO PROBLEMS with the status quo. -- Dave Blanchard <d...@killthe.net>
