Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Is C ready to become a safer language? Date: Sat, 10 Feb 2024 16:31:02 -0800 Organization: None to speak of Lines: 89 Message-ID: <8734tzdepl.fsf@nosuchdomain.example.com> References: <86eddl5bag.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="a3ea5551d1916ca86f611a52355c117b"; logging-data="119452"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+yyCrcfzJ1tp62MUOocdu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:RzwuARzLhqTIRBzM8CcdDKWP6QU= sha1:q25bgi0kmCE0+Sk8N4mGOD/kOJI= Xref: csiph.com comp.lang.c:382296 bart writes: > On 10/02/2024 01:59, Tim Rentsch wrote: >> bart writes: >> [...] >> >>> This is something which has long been of fascination to me: how >>> exactly do you get a C compiler to actually fail a program with a >>> hard error when there is obviously something wrong, while not also >>> failing on completely harmless matters. The only thing that *requires* a compiler to reject a translation unit is the #error directive. For any violation of a syntax rule or constraint, the standard only requires a *diagnostic message*, which can be a non-fatal warning. Most C compilers reject translation units for other reasons, and most have options to control those reasons. >> I think the answer is obvious: unless and until you find someone >> who works on a C compiler and who has exactly the same sense that >> you do of "when there is obviously something wrong" and of what >> conditions fall under the heading of "completely harmless matters", >> and also the same sense that you do of how a C compiler should >> behave in those cases, you won't get exactly what you want unless >> you do it yourself. > > > Take this function: > > void F() { > F(); > F(1); > F(1, 2.0); > F(1, 2.0, "3"); > F(1, 2.0, "3", F); > } > > Even if /one/ of those calls is correct, the other four can't be > possibly be correct as well. True, if by "correct" you mean "avoids undefined behavior". In fact only the first call is correct (and since it's endlessly recursive, it prevents any of the others from being executed, something that a compiler may or may not notice). No syntax error or constraint is violated (prior to C23), so no diagnostic is required. > Is there anyone here who doesn't think there is something obviously wrong? Something is wrong, and is easily avoided by not using old-style function declarations and definitions, which have been obsolescent since 1989. > How about this one: > > #include > int main(void) { > int a; > L1: > printf("Hello, World!\n"); > } > > Ramp up the warnings and a compiler will tell you about unused 'a' and > 'L1'. Use -Werror and the compilation will fail. Use -Werror and the compiler is non-conforming, since it will reject a translation unit for anything that the authors thought was worth warning about. Nevertheless, the -Werror option (or equivalent) can be useful. > Is there anyone here who thinks that running this program with those > unused identifiers is not completely harmless? Is there anyone here who thinks that a compiler can be clever enough to be trusted to determine whether an unused identifier is harmless or not? If you have an unused identifier, it's likely you've written something other than what you meant. A compiler can't know what you meant. There are very good reasons for warning about unused identifiers. They are very likely to be symptoms of bugs. If you don't want those particular warnings, there are likely to be ways to disable them. Aside from command-line arguments, `(void)a;` is likely to inhibit the warning. As for an unused label, you can delete it or comment it out. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Medtronic void Void(void) { Void(); } /* The recursive call of the void */