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 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 :
>
> if (test)
> 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:
>
> if (test)
> 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
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
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.
|
|