Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Harnden <richard.nospam@gmail.invalid>
Newsgroups: comp.lang.c
Subject: Re: how to make a macro work as a single line if stmt without braces
Date: Mon, 23 Sep 2024 11:37:34 +0100
Organization: A noiseless patient Spider
Lines: 133
Message-ID: <vcrgde$2ltof$1@dont-email.me>
References: <PaWdnZ3R-9zI6nP7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <vcm16e$1hm2u$1@dont-email.me> <vcn6m8$1n1vu$1@dont-email.me>
 <vcp0rq$26p7b$1@dont-email.me> <20240922080605.59@kylheku.com>
 <vcpeo0$28shf$1@dont-email.me> <87zfnzpgmv.fsf@nosuchdomain.example.com>
 <vcr138$2jlgq$1@dont-email.me> <vcr41q$2k34a$1@dont-email.me>
 <vcrbgv$2l5s8$1@dont-email.me>
Reply-To: nospam.harnden@invalid.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 23 Sep 2024 12:37:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="db54ebd46f9b7a07e3806f43ab3e4d3d";
	logging-data="2815759"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18uCm6n4oDB57wWR3kafLnyUYiWbojHWPM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Ty3telPxMxtTewGcnR+gvtIM5zM=
In-Reply-To: <vcrbgv$2l5s8$1@dont-email.me>
Content-Language: en-GB
Bytes: 5707

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.