Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: how to make a macro work as a single line if stmt without braces Date: Sun, 22 Sep 2024 17:47:23 +0100 Organization: A noiseless patient Spider Lines: 151 Message-ID: References: <20240922080605.59@kylheku.com> <20240922192726.000061fc@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 22 Sep 2024 18:47:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e2eb6ed07da02fb165003322cf58b126"; logging-data="2399540"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18pFcnEgWYnfbPVlwh7Sqhy" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:nFfNw4GKNZ959Orc2Ni3WnjLvSs= Content-Language: en-GB In-Reply-To: <20240922192726.000061fc@yahoo.com> Bytes: 5878 On 22/09/2024 17:27, Michael S wrote: > On Sun, 22 Sep 2024 16:56:47 +0100 > Bart wrote: > >> On 22/09/2024 16:11, Kaz Kylheku wrote: >>> On 2024-09-22, David Brown wrote: >>>> I am not suggesting overuse of braces. I am suggesting /good/ use >>>> of them. >>>> >>>> >>>> >>>> That's perhaps the most famous example of the havoc caused by >>>> omitting useful braces. >>>> >>>> Consistency and clarity is important. So is maintainability. >>>> Suppose, for example, you want to add a line "attempts++;" >>>> alongside the "ok++;" line. When the braces are there, the change >>>> is exactly that - add the new line you want. Without the original >>>> braces, you are now making changes to the structural syntax of the >>>> code as well when you add in original braces - or you are making a >>>> mistake in the code. >>> >>> My super advanced text editor from the future isn't letting me do >>> that: >>> >>> if (failed) >>> WARN("failed because..."); >>> else >>> ok++; >>> attempts++; // automatic deindent >>> >>> When I add a line after ok++, it deindents it to be at the same >>> indentation level as the if, before letting me type any content >>> into it. >>> >>> OK, I lied about the super advanced from the future. It's just Vim. >>> >>> Also GCC has been able to diagnose misleading indentation for some >>> years now. >>> >>> Between those two, there is nothing to worry about; just >>> concentrate on whether it looks prettier without the braces or with. >>> >> >> So, everyone has to write code exactly to the C standard. >> >> But when it comes to more practical matters, it's OK to depend on the >> arbitrary characteristics and abilities of whichever one of 1001 >> different text editors we happen to be using. >> >> Or we have to use a specific compiler with a specific set of options. >> >> > Also GCC has been able to diagnose misleading indentation for some >> > years now. >> >> How many years was that out of the last 52? How exactly do you turn >> it on? Since -Wall -Wpedantic -Wextra doesn't report it. >> > > My gcc warns just fine. > > void bar(int); > int foo(int x) { > if (x) > bar(x); > x -= 1; > return x; > } > > gcc -c -Wall foo.c > > foo.c: In function 'foo': > foo.c:3:3: warning: this 'if' clause does not guard... > [-Wmisleading-indentation] 3 | if (x) > | ^~ > foo.c:5:5: note: ...this statement, but the latter is misleadingly > indented as if it were guarded by the 'if' > 5 | x -= 1; > | ^ > That doesn't pick up a program that in my editor looks like this: ------------------------ int main(void){ total++; if (failed) WARN("failed because..."); else ok++; failed=0; } ------------------------ However, the first two indents use four spaces, but the third uses a hard tab that my editor shows as four spaces, but if I print it out to the console, it shows this: ------------------------ int main(void){ total++; if (failed) WARN("failed because..."); else ok++; failed=0; } ------------------------ That odd indentation is not picked up either. But it will say something if all indents used spaces or used hard tabs. If the language has explicit block delimiters (either mandatory braces, or endings like 'end'), then the problem simply wouldn't arise. That 'failed=0' line would either be before the delimiter or after it. The original example would look something like this: ------------------------ if (failed) { WARN("failed because..."); } else { ok++; } failed=0; ------------------------ That line is still mis-indented, but is now less likely to be taken to be part of that 'else' block. >> It is a failure in the design of the language. You can't really >> depend on ad hoc features of the tools you use to create and compile >> source code. >> >> At least guidelines can be used such as always using braces, then >> errors can occur less often. >> >> (I've been bitten by this endless times when trying to add debugging >> statements to existing code. If that code consistently used braces, >> then it wouldn't happen.) > > I wonder why I was not bitten by that more than, may be, 5 times in > 30+ years. Probably, I am doing something wrong. How you tried to debug other people's code via adding printf statements at strategic points?