Path: ...!2.eu.feeder.erje.net!feeder.erje.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 10:47:54 +0200
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <v5ohno$3rjfp$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 29 Jun 2024 10:47:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bcf251768de66e79f0a13b7d5c16be1a";
	logging-data="4050425"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2BUfvnoXlnDgffpNAYn6dx+itcfIkz7Q="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
Cancel-Lock: sha1:XVyQyNIdwnTYBMLG/7xU7Kyhcdk=
Content-Language: en-GB
In-Reply-To: <v5m2nl$39qob$3@dont-email.me>
Bytes: 4388

On 28/06/2024 12:19, bart 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.
> 
> 

It is certainly a reasonable idea to use gcc as a linter if your normal 
compile is poor at static checking.  I've done that myself in the past - 
in embedded development, you don't always get to choose a good compiler. 
  These days I'd be more likely to go for clang-tidy as a linter, and 
there's other more advanced tools available (especially if you have the 
money).

However, I don't see the point in doing any kind of compilation at all, 
until you have at least basic linting and static error checking in 
place.  If I've used the value of a variable without initialising it, I 
have no interest in running the program until that is fixed.  And if I 
don't want to run the program, I've no interest in compiling it.

So I simply can't comprehend why you'd want fast but pointless compiles 
regularly, then only occasionally check to see if the code is actually 
correct - or at least, does not contain detectable errors.

Now, if you were using one of these "big" linters that does simulations 
of your code and takes hours to run on a server machine before posting 
back a report, that's a different matter.  Tools like that run overnight 
or in batches, integrating with version control systems, automatic test 
setups, and so on.  But that's not what we are talking about.

Say tcc takes 0.2 seconds to compile your code, and "gcc -O2 -Wall" 
takes 3 seconds.  If gcc catches an error that you missed, that's 
probably going to save you between half and hour and several days 
finding the problem by trial-and-error debugging.