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 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: <20240625113616.000075e0@yahoo.com> <87ed8jnbmf.fsf@bsb.me.uk> <20240627201830.854@kylheku.com> <20240628032211.403@kylheku.com> 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 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 */