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

On 23/09/2024 10:14, David Brown wrote:

On 23/09/2024 09:06, Richard Harnden wrote:

On 23/09/2024 07:16, David Brown wrote:

On 22/09/2024 22:39, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

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

[...]

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.

>
The -Wmisleading-indentation option was added to gcc on 2015-05-12,
and incorporated into -Wall 2015-12-10.  gcc 6.1.0 has the option
and includes it in -Wall; gcc 5.3.0 does not.  (Are you using a gcc
release that old?)  It uses the -ftabstop= option (defaulting to 8)
to determine whether indentation lines up or not.
>
Inconsistent tabstops and mixing of spaces and tabs can certainly
cause problems.
>

>
That would be detected quite easily if the default for -ftabstop were, say, 27.  Then the chance of accidentally matching indents with tabs and spaces would be negligible.
>

>
Isn't that the opposite of what you want, though?
>

 What I would be looking for in this case is a warning if I had used tabs and spaces (for indents) at different places in the code.  If the tab setting is a sensible choice - typically 4 or 8 spaces worth - then you can easily have code that looks right (in the sense of having visual indents that match the real block structure) with one setting and looks wrong with a different setting.
 For example, you might write this code :
 <tb>if (test)
<tb><tb>foo();
<  ><  >bar();
 You've made an error here - you had intended to have both calls within the conditional.  With 4 spaces per tab when you made the error, this could be spotted by tools using tabstop settings of 4, or by a code reviewer with those settings.
 However, to tools or code reviewers with tabstop settings of 8, the code would appear as:
 <tb    >if (test)
<tb    ><tb    >foo();
<  ><  >bar();
 Now the indentation matches the syntactical structure, and the mistake is missed.
 With a tabstop of 27, the "if" and "bar()" lines do not match up, and the mistake can be flagged.
 Of course a tabstop of 27 is not necessary - anything other than a sane value of 4 or 8 would catch almost anything.  But having a bit of extra distance also catches cases of tab then space typos.
 And there could also be a warning that checked directly for mixes of tabs and spaces in indents.  But such mixes can happen when moving or copying code between files, and there are some people who like to mix 8-space tabs with 4 explicit spaces in their code.
 

If -ftabstops doesn't agree with your editor setting,
then gcc misses the errors, eg:
gcc, with the default -ftabstop=8, sees this ...
$ expand -t8 x.c
#include <stdio.h>
int main(void)
{
         int x=1;
         if ( x == 1 )
                 printf("x is 1\n");
         else
                 printf("x is not 1\n"); // tabs
         printf("x is %d\n", x); // spaces
         return 0;
}
... and the indentation doesn't match up, so it's happy.
$ gcc -Wmisleading-indentation -ftabstop=8 x.c
(nothing)
But, in my editor, I see this ...
$ expand -t4 x.c
#include <stdio.h>
int main(void)
{
     int x=1;
     if ( x == 1 )
         printf("x is 1\n");
     else
         printf("x is not 1\n"); // tabs
         printf("x is %d\n", x); // spaces
     return 0;
}
... and then indentation does match up, so I want the error flagged.
Which it does:
$ gcc -Wmisleading-indentation -ftabstop=4 x.c
x.c: In function ‘main’:
x.c:9:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
     9 |     else
       |     ^~~~
x.c:11:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’
    11 |         printf("x is %d\n", x); // spaces
       |         ^~~~~~
So, to me anyway, telling gcc that tabstops are 27 would suppress all the useful warnings.