Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Concatenated if and preprocessor Date: Fri, 14 Mar 2025 14:10:28 -0700 Organization: None to speak of Lines: 48 Message-ID: <87zfhniaij.fsf@nosuchdomain.example.com> References: <86frjfsgtb.fsf@linuxsc.com> <86bju3s5vp.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 14 Mar 2025 22:10:32 +0100 (CET) Injection-Info: dont-email.me; posting-host="bbf3b2da6e551caad2cd296cab2812d3"; logging-data="2179411"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18x/8aTqz+7vzbQ045iVF3o" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:hR8PZXq7+XaNPLtXCXVwIwmZLlc= sha1:MtZjeXteg/el1f/OuUxH7vCc3vE= Tim Rentsch writes: > Richard Harnden writes: >> On 14/03/2025 16:44, Tim Rentsch wrote: >>> for( int just_once = 1; just_once; just_once = 0 ){ >> >> Any reason not to say ... >> >> do { >> ... >> } while (0); >> >> ... ? > > In fact using do/while(0) is what I first wrote. But then > I thought, oh wait, what if an overzealous compiler gives > a warning because the while() expression is always false? :-/ > > It's because of examples like this that I am wary of rules > like "enable all warnings" and "treat any warning condition > as an error." I recently ran across a set of coding standard > rules that included these rules: not just /some/ warning > conditions, but ALL warning conditions. I still don't know > if they were literally serious. (And my understanding is > clang has a -Weverything option, which enables all warning > conditions that clang is able to test for, no matter how > silly.) I've worked under such coding standards. Perhaps surprisingly, I haven't found them to be terribly inconvenient. I rarely ran into a warning that was inordinately difficult to avoid. I can see that "clang -Weverything" would cause problems. The most common inconvenience was that if I experimentally commented out some code, and it caused some variable not to be referenced, the build would fail. (I could just add `(void)foo;` to avoid that.) To be clear, this was not code that I intended to commit. I can imagine that there could be problems if a newer version of the compiler produced new warnings, but we didn't often change compilers. (In one obscure case, I wrote a wrapper script that could be installed in $PATH as "gcc" that would invoke the real gcc and filter out a particular warning. The wrapper was necessary due to the behavior of a build script, not to an explicit coding standard.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */