Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Sat, 29 Jun 2024 17:11:19 +0100
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <v5pbn7$75a$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 29 Jun 2024 18:11:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8999aade17fef69a77001a25d1c0d2c5";
	logging-data="7338"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX184Z3aPSPOg3qKUvR0Q4kF7"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:g/jnC3D7mZAy77iXjU4fAMJF6Sw=
Content-Language: en-GB
In-Reply-To: <86le2ndajg.fsf@linuxsc.com>
Bytes: 4097

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.

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.

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