Sujet : Re: Baby X is bor nagain
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 29. Jun 2024, 16:14:23
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v5p4rv$3u92q$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
User-Agent : Mozilla Thunderbird
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
}
-------------------------