Re: More C type errors by default for GCC 14

["Arsen Arsenović" <arsen@aarsen.me>]

[-- Attachment #1: Type: text/plain, Size: 4833 bytes --]


Dave Blanchard <dave@killthe.net> writes:

> 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.

It doesn't work fine on x86 (or any other arch).  See the two points
above that you've baselessly dismissed.

>> - 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.

Employment of such language is unwanted, but sadly, I'm not surprised.

>> 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.

You've actively and baselessly dismissed the general case (and are, and
I say this with a lot of confidence, missing subtle bugs on your
system).

>> 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.

The number of errors is far smaller than you estimate.  We've been
working through the queue for a while and have a decent idea of the
scope of the problem, and it is very manageable.

On top of that, the errors in question are largely trivial to fix,
unlike detecting the errors introduced by the current 'working' code.

>> 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?

They compile fine, and run without subtle bugs caused by constructs that
have been invalid for over 20 years.

>> 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.

It doesn't work fine.  See the points that you've dismissed above.

The situation was also far simpler decades ago, and the actual trade-off
far greater (now invalid code is the exception).

>> 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.

This seems irrelevant, and is not an accurate representation of who's
involved in the process.

>> 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.

Current code is subtly broken.  It is a disservice to users to pretend
otherwise.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]