Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Sat, 29 Jun 2024 16:23:06 -0700
Organization: None to speak of
Lines: 52
Message-ID: <878qynxrj9.fsf@nosuchdomain.example.com>
References: <v494f9$von8$1@dont-email.me> <v5c86d$11ac7$1@dont-email.me>
	<JEheO.108086$ED9b.74955@fx11.iad> <v5cblg$11q0j$1@dont-email.me>
	<gEieO.108089$ED9b.25598@fx11.iad> <20240625113616.000075e0@yahoo.com>
	<mUzeO.141609$Cqra.55051@fx10.iad> <v5elql$1jmii$1@dont-email.me>
	<m3BeO.24907$Gurd.16179@fx34.iad> <v5empd$1jndv$2@dont-email.me>
	<v5eph4$1k6a9$1@dont-email.me> <87ed8jnbmf.fsf@bsb.me.uk>
	<v5jhls$2m7np$1@dont-email.me> <v5jm32$2nqvp$1@dont-email.me>
	<v5k3v2$2qllm$1@dont-email.me> <v5kfst$2svt3$1@dont-email.me>
	<v5kmlm$2u918$1@dont-email.me> <20240627201830.854@kylheku.com>
	<v5m2nl$39qob$3@dont-email.me> <20240628032211.403@kylheku.com>
	<v5p4rv$3u92q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 30 Jun 2024 01:23:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bc3e962b409675c7954f5b09442f496d";
	logging-data="171512"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19nbbBCobRjqgXXUcyeEBn9"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:j39WLIEBItH879HFIGWzph9rQJM=
	sha1:DJ6NpcyXpskShMLtQWIU27puYOg=
Bytes: 3957

bart <bc@freeuk.com> writes:
[...]
> I'm not interested in comments that you COULD have provided enough
> options to make those 1 and 3 fatal errors, and possibly taken care of
> 2 and 4 as well.

And that's your problem.  Serious developers don't use gcc without
options.  The fact that gcc's default behavior changed between
releases 10 and 14 is interesting, I suppose, but (a) it's a gcc
issue, not a C issue, and (b) since gcc lets you ask for reasonable
diagnostics, it's just not that big a deal.

Sure, some programmers use gcc with no warning or dialect options.
I do it myself when I'm compiling a quick and dirty program.

The defaults are the way they are for historical reasons.  gcc can
still be used to compile old code that might not conform to the
current standard, for example code that uses implicit int.

I presume your own compiler behave the way you want them to when
invoked without additional options.  gcc doesn't.  Nobody here can
do anything about that.

> What is interesting is that Gcc 14 decided to make those hard errors
> by default. WHY? What was wrong with how earlier versions did it?

Earlier versions of gcc let too many errors through by default.
Later versions let fewer errors through by default.  I don't know
what led to the decision to make gcc 14 more stringent by default.
If you're that curious, I'm sure you can find some kind of release
notes.  (I don't care enough to go looking, and I suspect you
don't either).

> For years I've been complaining about that, with people telling I was
> an idiot, that I should RTFM, that I should do this or that. And now
> suddenly gcc 14 does what I said it should be doing. Maybe I had a
> point after all!

I don't recall anyone telling you you're an idiot because you've
said that gcc is too lax by default.  I certainly wouldn't, because
I agree with you.  I'd prefer for gcc with no options to treat
syntax errors and constraint violations as fatal errors.  The gcc
maintainers aren't going to change the default behavior because you
or I want them to, so I don't waste my time complaining about it.
But I know how to make it behave (mostly) the way I want it to.
And so do you.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */