Re: how to make a macro work as a single line if stmt without braces

Michael S <already5chosen@yahoo.com> writes:

On Sun, 22 Sep 2024 16:56:47 +0100
Bart <bc@freeuk.com> wrote:
>

On 22/09/2024 16:11, Kaz Kylheku wrote:
>

On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:
>

I am not suggesting overuse of braces.  I am suggesting /good/ use
of them.
>
<https://www.synopsys.com/blogs/software-security/
    understanding-apple-goto-fail-vulnerability-2.html>
>
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;
      |     ^
>
>

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.

My long-standing habit is to write this

   if(x)  bar(x);

or this

   if(x){
      bar(x);
   }

but never this

   if(x)
      bar(x);

The reason for this habit is that many years ago I got bitten by
trying to add a line in the last case.  The habit subsequently
adopted has proven very effective at eliminating such errors.

The idea of changing the language to always require braces is
unnecessary and wasteful (besides being a non-starter for purely
practical reasons).