Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Sat, 29 Jun 2024 19:42:01 +0200
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <v5ph1a$1bkv$1@dont-email.me>
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> <86le2ndajg.fsf@linuxsc.com>
 <v5pbn7$75a$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jun 2024 19:42:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="22faf9017835e57ca0db4be45702a84c";
	logging-data="44703"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ikbNk0D3aeYcA0thu0z3vNNu20zuNlqU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
Cancel-Lock: sha1:TH0DCUOfPCZh+X4R5biB95WkMTw=
Content-Language: en-GB
In-Reply-To: <v5pbn7$75a$1@dont-email.me>
Bytes: 5839

On 29/06/2024 18:11, bart wrote:
> On 29/06/2024 16:38, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 28/06/2024 11:26, Kaz Kylheku wrote:
>>>
>>>> On 2024-06-28, bart <bc@freeuk.com> wrote:
>>>>
>>>>> On 28/06/2024 04:23, Kaz Kylheku wrote:
>>>>>
>>>>>> On 2024-06-27, bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>>> And for most of /my/ compiles, the code produced by gcc-O0 is
>>>>>>> fast enough.  It also about the same speed as code produced by
>>>>>>> one of my compilers.
>>>>>>>
>>>>>>> So I tend to use it when I want the extra speed, or other
>>>>>>> compilers don't work, or when a particular app only builds
>>>>>>> with that compiler.
>>>>>>>
>>>>>>> Otherwise the extra overheads are not worth the bother.
>>>>>>
>>>>>> How good are your diagnostics compared to GCC -O2, plus -Wall
>>>>>> and -W?
>>>>>
>>>>> Using products like tcc doesn't mean never using gcc.
>>>>> (Especially on Linux where you will have it installed anyway.)
>>>>>
>>>>> You can use the latter to do extra, periodic checks that the
>>>>> simpler compiler may have missed, or to produce faster production
>>>>> builds.
>>>>>
>>>>> But gcc is not needed for routine compilation.
>>>>
>>>> Catching common bugs in routine compilation is better than once
>>>> a month.
>>>>
>>>> You could be wasting time debugging something where GCC would have
>>>> told you right away you have something uninitialized or whatever.
>>>
>>> Let's take the C program below.  It has 4 things wrong with it,
>>> marked with comments.
>>>
>>> [...]
>>
>> People are never going to take you seriously as long as
>> you keep offering what are obviously strawman arguments,
>> and especially ones where you know better but pretend
>> that you don't.
> 
> You've perhaps missed my main point, which was that gcc 14 now reports 
> hard errors BY DEFAULT for things which I have argued in the past should 
> be hard errors by default.

I don't remember anyone disagreeing with you that some things would be 
better as hard errors by default.  People have been quite happy with the 
idea that code that breaks C syntax rules or constraint rules should be 
hard errors.  But they disagree with you on some of your hard errors - 
code that we all think is bad code and almost certainly an error, but 
which does not break the rules of standard C can be a warning by 
default, but should not be an error by default.

gcc, however, is restricted and limited by its past - the developers do 
not lightly make changes that will result in compilation failures of 
code that previously compiled fine and had been tested to run correctly. 
  Such changes - as made for gcc 14 - are only done after long 
discussion and long testing with existing code bases.

Many of us thing it would be better if gcc's warnings and errors were a 
lot stricter by default.  But we understand the reasons why gcc can't 
change these much, and we understand how to choose the checking levels 
with flags so that we can use gcc the way we want it.  Telling you "just 
use -Wall", or similar, is advice and help - it is not saying that we 
like a lax compiler by default.

> 
> You've probably also missed my secondary point, which was asking WHY 
> that change was made, since all that people had to do to get that 
> behaviour was to jump through a number of hoops as I've always been told 
> to do. Apparently that was not good enough!
> 
> I've also learnt something interesting. Which is that whatever the 
> current version of gcc does is always right, and I'm always wrong if I 
> suggest it should be any different.
> 

You are wrong when you continually misrepresent what others say.  When 
people tell you the facts - be it about C or gcc - it is not the same as 
saying we necessarily like those facts.

> But if gcc suddenly starts doing what I'd advocated, then according to 
> you I'm still wrong! So I can never win.
> 

You can win when you stop intentionally misunderstanding, and start 
listening.