Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #388454 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  how to make a macro work as a single line if stmt without braces Mark Summerfield <mark@qtrac.eu> - 2024-09-21 07:35 +0000
    Re: how to make a macro work as a single line if stmt without braces Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-21 08:10 +0000
    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-21 10:47 +0200
      Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 12:27 -0700
        Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-21 21:11 +0100
        Re: how to make a macro work as a single line if stmt without braces Opus <ifonly@youknew.org> - 2024-09-21 22:39 +0200
        Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 14:54 -0700
          Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 20:05 -0700
            Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 21:33 -0700
            Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 14:15 +0200
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 03:38 -0700
        Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 13:59 +0200
          Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-22 15:11 +0000
            Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-22 16:56 +0100
              Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-22 19:27 +0300
                Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-22 17:47 +0100
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-24 07:36 -0700
                  Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-24 07:52 -0700
                    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-24 17:24 +0200
                    Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 17:22 +0100
                      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-24 12:28 -0700
                    Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 01:43 -0700
                  Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 17:35 +0100
                    Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-24 12:30 -0700
                      Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 20:42 +0100
                    Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-24 19:59 +0000
                      Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 21:12 +0100
                        Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-24 22:36 +0000
              Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-22 13:39 -0700
                Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 08:16 +0200
                  Re: how to make a macro work as a single line if stmt without braces Richard Harnden <richard.nospam@gmail.invalid> - 2024-09-23 08:06 +0100
                    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 11:14 +0200
                      Re: how to make a macro work as a single line if stmt without braces Richard Harnden <richard.nospam@gmail.invalid> - 2024-09-23 11:37 +0100
                        Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 14:22 +0200
            Modern text editor - 'bout time someone paid attention to keeping the thread title relevant!!! (Was: how to make a macro work as a single line if stmt without braces) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-22 16:03 +0000
            Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 18:03 +0200
        Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 05:02 -0700
          Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-28 20:30 +0300
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 21:53 -0700
              Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-29 12:48 +0300
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-29 19:18 -0700
                Re: how to make a macro work as a single line if stmt without braces Alan Mackenzie <acm@muc.de> - 2024-09-30 15:05 +0000
          Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-28 21:02 -0700
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 22:47 -0700
              Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-29 07:41 -0700
                Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-29 18:04 +0300
                Re: how to make a macro work as a single line if stmt without braces scott@slp53.sl.home (Scott Lurndal) - 2024-09-29 18:30 +0000
                Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-29 16:39 -0700
                  Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-30 02:29 +0000
                    Re: how to make a macro work as a single line if stmt without braces Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-30 11:26 +0200
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-29 18:39 -0700
                Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-30 02:03 +0000
                Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-30 13:17 +0200
    Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-21 10:13 +0100
      Re: how to make a macro work as a single line if stmt without braces Mark Summerfield <mark@qtrac.eu> - 2024-09-21 09:53 +0000
    Re: how to make a macro work as a single line if stmt without braces Ike Naar <ike@sdf.org> - 2024-09-21 09:15 +0000
      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 14:44 -0700
    Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-21 06:07 -0700
      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 15:55 -0700
    Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 12:17 -0700
    Re: how to make a macro work as a single line if stmt without braces Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-09-21 21:18 +0000
      Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-24 06:18 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#388520

Bart <bc@freeuk.com> writes:
> On 24/09/2024 15:52, Andrey Tarasevich wrote:
[...]
>> The same applies to
>>    if(x)
>>      bar(x);
>> This is the right thing to do. It is the most readable and elegant
>> way to write a simple `if`.
>
> Well, it is the ONLY way C provides to write the branches of an
> if-statement. Each only takes a single statement.

You misunderstood.  Andrey was saying that
    if(x)
      bar(x);
is right and
    if(x) bar(x);
is wrong.  Of course both are legal; Andrey is arguing that nobody
should ever use the second form.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#388529

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 09/24/24 7:36 AM, Tim Rentsch wrote:
>
>> 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.
>
> It is just weird.
>
> This is no different from insisting in using "Yoda conditions",
> claiming that "many years ago I was bitten by an accidental =
> in place of ==".

Don't be silly, of course they are different.  There is nothing
artificial about surrounding controlled statements with braces.
And writing braceless single-line if()s in cases where there
is only a single controlled statement is something I was already
doing - I didn't adopt it as a reaction to something that
happened with multi-line if()s.

> In reality we all know that regardless of how many scary
> stories someone might tell about dangers of accidental
> assignment in place of comparison, it just does not happen.
> There's no such issue.  People just don't make this mistake.

Your view is contradicted by objective reality.

> The same applies to
>
>   if(x)
>     bar(x);
>
> This is the right thing to do.  It is the most readable and
> elegant way to write a simple `if`.

I think you need to learn the difference between a statement
of opinion and a statement of fact.

> And the dreaded "one day you will add a line and suffer" just
> doesn't happen.  There's no such issue.  People just don't make
> this mistake.

Making a false statement twice doesn't make it true.

[toc] | [prev] | [next] | [standalone]

#388519

On 24/09/2024 15:36, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
> 

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

Well, practically it is not difficult.

I started modifying my compiler to do it, but found I already had that 
option, which was a hard-coded value in the source. It took a minute to 
reenable it. Support for it requires 2-3 lines of code.

However, that makes an exception for if-else chains, so that you can 
still write:

   if (c1) {} else if (c2) {} else if (c3) {}

instead of needing:

   if (c1) {} else {if (c2) {} else {if (c3) {}}}

(Maybe the language needs a construct like 'elif', as is used in 
languages like, say, C's own preprocessor! HTH did that end up with the 
sensible syntax while the main language was stuck with the rubbish one?)

BTW with mandatory braces enforced, my generated-C applications still 
build with no problems. Because generated code always uses braces. There 
is no point in leaving them out, other than perhaps ending up with 0.5% 
smaller output.

[toc] | [prev] | [next] | [standalone]

#388521

Bart <bc@freeuk.com> writes:
> On 24/09/2024 15:36, Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> The idea of changing the language to always require braces is
>> unnecessary and wasteful (besides being a non-starter for purely
>> practical reasons).
>
> Well, practically it is not difficult.

Changing a compiler to require compound statements would not be
difficult.  Changing the language in that way would be completely
impractical, because it would break existing code.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#388522

On 24/09/2024 20:30, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 24/09/2024 15:36, Tim Rentsch wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>> The idea of changing the language to always require braces is
>>> unnecessary and wasteful (besides being a non-starter for purely
>>> practical reasons).
>>
>> Well, practically it is not difficult.
> 
> Changing a compiler to require compound statements would not be
> difficult.  Changing the language in that way would be completely
> impractical, because it would break existing code.

But not new code that uses compound statements, which is will still be 
compatible with compilers that don't enforce it.

And as I said, it doesn't break my generated code, and the first 
substantial manually written program I tried worked too.

Adding such an option, if it doesn't already exist, would be trivial.

[toc] | [prev] | [next] | [standalone]

#388523

On 2024-09-24, Bart <bc@freeuk.com> wrote:
> (Maybe the language needs a construct like 'elif', as is used in 

The language doesn't need such a construct in order for a compiler
to implement it internally.

You just have to treat the token sequence   else if  as a supertoken.

Doing it at the grammar level may require two symbols of lookahead,
which is a a problem for off-the-shelf parser generation tooling based
on LALR(1) and whatnot.

A possible trick is to handle it at the lexical level. The pattern
else{WSP}if can be recognized as a single token, assigned its own
enumeration symbol. {WSP} is arbitrary whitespace. (We assume
comments have been stripped by a lower preprocessing phase.)

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#388524

On 24/09/2024 20:59, Kaz Kylheku wrote:
> On 2024-09-24, Bart <bc@freeuk.com> wrote:
>> (Maybe the language needs a construct like 'elif', as is used in
> 
> The language doesn't need such a construct in order for a compiler
> to implement it internally.
> 
> You just have to treat the token sequence   else if  as a supertoken.
> 
> Doing it at the grammar level may require two symbols of lookahead,
> which is a a problem for off-the-shelf parser generation tooling based
> on LALR(1) and whatnot.

That sounds as much of a hack as making a special case for 'else if' so 
that it doesn't need 'else {if' (and a matching } later on) when 
enforcing compound statements for such blocks.

One consequence of how it works now is that if I write:

     if (a) {}
     else if (b) {}
     else if (c) {}
     else {}

then use a tool I have to visualise C code in my syntax, it generates:

     if a then
     else
         if b then
         else
             if c then
             else
             fi
         fi
     fi

The nested nature is revealed. If there were 50 'else if' links, the 
output would disappear off to the right.

With elif, elsif etc, the compiler has the option to keep the internal 
structure linear (which also means it will not put pressure on the stack 
if somebody decides to write a million of them).

[toc] | [prev] | [next] | [standalone]

#388525

On 2024-09-24, Bart <bc@freeuk.com> wrote:
> On 24/09/2024 20:59, Kaz Kylheku wrote:
>> On 2024-09-24, Bart <bc@freeuk.com> wrote:
>>> (Maybe the language needs a construct like 'elif', as is used in
>> 
>> The language doesn't need such a construct in order for a compiler
>> to implement it internally.
>> 
>> You just have to treat the token sequence   else if  as a supertoken.
>> 
>> Doing it at the grammar level may require two symbols of lookahead,
>> which is a a problem for off-the-shelf parser generation tooling based
>> on LALR(1) and whatnot.
>
> That sounds as much of a hack as making a special case for 'else if' so 
> that it doesn't need 'else {if' (and a matching } later on) when 
> enforcing compound statements for such blocks.

It's a hack, but you can completely hide it at the grammar level; you
can write your grammar with the assumption that there is an ELIF token,
so that the syntax is identical to that found in languages that have
elif or elsif. Just the lexical level, it is spelled by two words.

> One consequence of how it works now is that if I write:
>
>      if (a) {}
>      else if (b) {}
>      else if (c) {}
>      else {}
>
> then use a tool I have to visualise C code in my syntax, it generates:

It behooves C processing tools to grok "else if" where it makes sense.

>      if a then
>      else
>          if b then
>          else
>              if c then
>              else
>              fi
>          fi
>      fi

Note that in this type of language, an "elif" is helpful, because
every "else if" introduces an "if", which must be matched by its own
"fi", whereas an "elif" doesn't require its own closing keyword.

In other words, "elif" is more than just a contraction for "else if"; it
eliminates "fi".

In the preprocessor, it is different; there is an #endif.

If the above language has elif, then a conversion can be applied
by the rewrite rule

  {if/elif} A then B else if C then [...] fi fi

  ->

  {if/elif} A then B elif C then [...] fi

this can be repeatedly applied until there is no match for the
left hand side.

> The nested nature is revealed. If there were 50 'else if' links, the 
> output would disappear off to the right.
>
> With elif, elsif etc, the compiler has the option to keep the internal 
> structure linear (which also means it will not put pressure on the stack 
> if somebody decides to write a million of them).

The option to keep the AST structure linear is there regardless,
as I pointed out; compilers writers can easily pretend that "else if"
is special.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#388507

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.

> It is a failure in the design of the language.

I wouldn't quite go that far, but I partly agree with you.  Perl
requires braces on compound statements, and I've largely adopted
that style in my own C code.  If C had required braces (requiring
a compound-statement in most contexts that currently require a
statement), certain errors would have been more difficult to make.
And you could still write one-line if statements in the cases
where they might be clearer:

    if (cond1) { do_this(); }
    if (cond2) { do_that(); }
    if (cond3) { do_the_other(); }

However, there is zero chance that this will be changed in a future
version of C.  It would break too much existing code.  Which is
why we're discussing ways to write reliable code given the existing
language rules.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#388509

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.

[toc] | [prev] | [next] | [standalone]

#388510

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?

[toc] | [prev] | [next] | [standalone]

#388511

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.

[toc] | [prev] | [next] | [standalone]

#388512

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.

[toc] | [prev] | [next] | [standalone]

#388513

On 23/09/2024 12:37, Richard Harnden wrote:

> So, to me anyway, telling gcc that tabstops are 27 would suppress all 
> the useful warnings.
> 

I see what you mean.

Fair enough - it seems that picking a tabstop setting that matches your 
editor settings could catch some mistakes that a different tabstop 
setting would not.  Equally, I think from my example, having a different 
tabstop setting would catch other errors that one matching your editor 
would not.

And in my brief testing, using gcc 13, it failed to catch several cases 
of indentation mismatches, regardless of the tabstop setting, which is a 
bit disappointing.

I think perhaps the best solution would be for gcc to warn about 
space/tab mismatches as well, regardless of the tabstop settings.

[toc] | [prev] | [next] | [standalone]

#388501 — Modern text editor - 'bout time someone paid attention to keeping the thread title relevant!!! (Was: how to make a macro work as a single line if stmt without braces)

In article <20240922080605.59@kylheku.com>,
Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
...
>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.

Actually, there are more than a few C shibboleths that date back to the days
of yore when both editors and C compilers were a lot less capable than they
are today - with the result being, as you imply, that they are, nowadays,
pretty much irrelevant.

One such example is the old chestnut of:

    if (a = 0) ...

My old Turbo C compiler caught this back in 1987.

And yet people still talk about it today.

-- 
When I was growing up we called them "retards", but that's not PC anymore.
Now, we just call them "Trump Voters".

The question is, of course, how much longer it will be until that term is also un-PC.

[toc] | [prev] | [next] | [standalone]

#388502

On 22/09/2024 17: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.
> 

I am happiest with a bracing style that looks good (in my subjective 
opinion), is easily understandable, is hard for humans to misinterpret, 
is automated to a large extent by many editors, and is checked by the 
compiler.  I agree that mistakes due to indentation errors should be a 
thing of the past for people who use decent modern tools.  But I'm a 
seatbelt and airbag kind of programmer, at least when there is no 
runtime cost - I prefer a method that is inherently hard to get wrong 
and is /also/ checked and automated by tools.

[toc] | [prev] | [next] | [standalone]

#388539

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

> And don't use "Egyptian" braces [the style used in the
> first edition of The C Programming Language, by Kernighan
> and Ritchie].
>
> This is the proper formatting style with braces
>
>   if (failed)
>   {
>     ...
>   }
>   else
>   {
>     ...
>   }
>
> The vertical spacing introduced by the `{` line provides
> separation between condition and the branch, which makes
> your code much more readable.  [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

[toc] | [prev] | [next] | [standalone]

#388540

On Sat, 28 Sep 2024 05:02:05 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 
> [...]
> 
> > And don't use "Egyptian" braces [the style used in the
> > first edition of The C Programming Language, by Kernighan
> > and Ritchie].
> >
> > This is the proper formatting style with braces
> >
> >   if (failed)
> >   {
> >     ...
> >   }
> >   else
> >   {
> >     ...
> >   }
> >
> > The vertical spacing introduced by the `{` line provides
> > separation between condition and the branch, which makes
> > your code much more readable.  [...]  
> 
> What qualities does this layout style have that make it "more
> readable", other than it being one that you like or prefer?

{ at the same level of indentation as its matching }

[toc] | [prev] | [next] | [standalone]

#388549

Michael S <already5chosen@yahoo.com> writes:

> On Sat, 28 Sep 2024 05:02:05 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>
>> [...]
>>
>>> And don't use "Egyptian" braces [the style used in the
>>> first edition of The C Programming Language, by Kernighan
>>> and Ritchie].
>>>
>>> This is the proper formatting style with braces
>>>
>>>   if (failed)
>>>   {
>>>     ...
>>>   }
>>>   else
>>>   {
>>>     ...
>>>   }
>>>
>>> The vertical spacing introduced by the `{` line provides
>>> separation between condition and the branch, which makes
>>> your code much more readable.  [...]
>>
>> What qualities does this layout style have that make it "more
>> readable", other than it being one that you like or prefer?
>
> { at the same level of indentation as its matching }

Certainly it is true that the layout style shown has the open
brace at the same level of indentation as the matching close
brace.  What about that property makes this layout "more
readable"?  The statement given sounds like a tautology -
I don't see that any new information has been added.

[toc] | [prev] | [next] | [standalone]

#388551

On Sat, 28 Sep 2024 21:53:06 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On Sat, 28 Sep 2024 05:02:05 -0700
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >  
> >> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> >>
> >> [...]
> >>  
> >>> And don't use "Egyptian" braces [the style used in the
> >>> first edition of The C Programming Language, by Kernighan
> >>> and Ritchie].
> >>>
> >>> This is the proper formatting style with braces
> >>>
> >>>   if (failed)
> >>>   {
> >>>     ...
> >>>   }
> >>>   else
> >>>   {
> >>>     ...
> >>>   }
> >>>
> >>> The vertical spacing introduced by the `{` line provides
> >>> separation between condition and the branch, which makes
> >>> your code much more readable.  [...]  
> >>
> >> What qualities does this layout style have that make it "more
> >> readable", other than it being one that you like or prefer?  
> >
> > { at the same level of indentation as its matching }  
> 
> Certainly it is true that the layout style shown has the open
> brace at the same level of indentation as the matching close
> brace.  What about that property makes this layout "more
> readable"?  The statement given sounds like a tautology -
> I don't see that any new information has been added.

It makes it easier to see where block starts and where it ends. Opening
{ followed by empty line is more bold visually than 'if something { ' or
then '} else {'.

Now, I can live with both styles, but can see why many people prefer
style advocated by Andrey.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web