Path: ...!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 15:14:23 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <v5p4rv$3u92q$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 29 Jun 2024 16:14:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8999aade17fef69a77001a25d1c0d2c5";
	logging-data="4138074"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18nBn+IfaqY64Z0ZYkaxVJv"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dIwal+wCUrKFrlJDV2zeCsP45Rs=
Content-Language: en-GB
In-Reply-To: <20240628032211.403@kylheku.com>
Bytes: 4965

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.

Gcc 10, run with no extra options, gives me warnings about (1) and (3); 
the others are ignored.

Gcc 14, also with no extra options, gives errors for (1) and (3).

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.

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?

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!

Anyway, my 'mcc' compiler already reports 1 and 3 as hard errors.

My older bcc compiler reported 4 as a hard error unless an override was 
used.

And for a while, it could detect 2; but I had to remove it because 
sometimes such code is valid; it would have needed the C to be changed, 
with a dummy return, to enable it to pass.

So it's not as though a little compiler does no checking at all; it can 
pick up obvious things that a bigger one misses or does not treat 
seriously. Gcc 10 (perhaps even up to 13) can produce an EXE which 
someone can run; my mcc wouldn't allow it.

BTW if I try to reproduce this program in my systems language, then all 
4 are hard errors. My language is stricter. My 'linting' is poor, that's 
all.


-------------------------
#include <stdio.h>
#include <stdlib.h>

int F(void) {
     return;             // 1 No value
}

int G(void) {
     if (rand())
         return 0;
}                       // 2 Possibly running into end

int main() {
     char s[10];
     char *p = &s;       // 3 Wrong types

     main(123);          // 4 Unchecked arg types
}
-------------------------