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

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

Effective uses of c `goto' statement

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

Contents

  Effective uses of c `goto' statement kevin shell <kevin@fedora.osfans.org> - 2020-12-02 16:42 +0800
    Re: Effective uses of c `goto' statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-02 01:07 -0800
    Re: Effective uses of c `goto' statement Anton Shepelev <anton.txt@gmail.com> - 2020-12-02 20:18 +0300
      Re: Effective uses of c `goto' statement Anton Shepelev <anton.txt@gmail.com> - 2020-12-02 20:56 +0300
      Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-02 19:30 +0100
        Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-02 19:35 +0000
          Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-02 21:05 +0100
    Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-02 18:07 +0000
      Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-02 19:33 +0100
    Re: Effective uses of c `goto' statement Siri Cruise <chine.bleu@yahoo.com> - 2020-12-02 10:22 -0800
      Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-02 20:18 +0000
        Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-02 23:16 +0100
          Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-03 01:31 +0000
            Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-03 08:39 +0100
              Re: Effective uses of c `goto' statement Siri Cruise <chine.bleu@yahoo.com> - 2020-12-02 23:48 -0800
              Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-03 17:49 +0000
            Re: Effective uses of c `goto' statement Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-03 17:09 +0100
        Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 08:28 -0800
          Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-05 12:41 -0500
            Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 05:03 -0800
              Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-06 08:51 -0500
                Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-06 08:56 -0500
                Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 18:43 -0800
              Re: Effective uses of c `goto' statement Öö Tiib <ootiib@hot.ee> - 2020-12-06 05:58 -0800
                Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 16:54 -0800
          Re: Effective uses of c `goto' statement Siri Cruise <chine.bleu@yahoo.com> - 2020-12-05 10:01 -0800
            Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 04:55 -0800
      Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-03 21:20 -0800
        Re: Effective uses of c `goto' statement Siri Cruise <chine.bleu@yahoo.com> - 2020-12-03 21:50 -0800
          Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-03 23:06 -0800
            Re: Effective uses of c `goto' statement Siri Cruise <chine.bleu@yahoo.com> - 2020-12-04 00:27 -0800
    Re: Effective uses of c `goto' statement foo <opaquefoo@gmail.com> - 2020-12-02 11:03 -0800
      Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-02 21:02 +0100
        Re: Effective uses of c `goto' statement Öö Tiib <ootiib@hot.ee> - 2020-12-05 03:04 -0800
          Re: Effective uses of c `goto' statement Öö Tiib <ootiib@hot.ee> - 2020-12-05 03:36 -0800
            Good thing this isn't a Python group (Was: Effective uses of c `goto' statement) gazelle@shell.xmission.com (Kenny McCormack) - 2020-12-05 11:45 +0000
              Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement) David Brown <david.brown@hesbynett.no> - 2020-12-05 14:38 +0100
                Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-12-06 11:00 +0000
                  Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement) gazelle@shell.xmission.com (Kenny McCormack) - 2020-12-06 12:33 +0000
                  Re: Good thing this isn't a Python group Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-06 14:09 -0800
                    Re: Good thing this isn't a Python group Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-12-08 21:01 +0000
            Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-05 14:37 +0100
    Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-02 20:07 +0000
    Re: Effective uses of c `goto' statement Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-03 17:10 +0100
    Re: Effective uses of c `goto' statement "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-03 15:40 -0800
      Re: Effective uses of c `goto' statement Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-03 16:14 -0800
      Re: Effective uses of c `goto' statement kevin shell <kevin@fedora.osfans.org> - 2020-12-04 16:29 +0800
        Re: Effective uses of c `goto' statement "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-04 07:09 -0800
        Re: Effective uses of c `goto' statement "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-04 10:14 -0800
      Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-04 11:19 +0000
        Re: Effective uses of c `goto' statement Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-04 04:35 -0800
          Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-04 13:50 +0000
            Re: Effective uses of c `goto' statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-04 10:49 -0800
        Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-04 13:09 +0000
          Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-04 14:03 +0000
    Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-03 23:02 -0800
      Re: Effective uses of c `goto' statement Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-04 19:38 +0100
        Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 01:29 -0800
      Re: Effective uses of c `goto' statement kegs@provalid.com (Kent Dickey) - 2020-12-09 00:23 -0600
        Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-09 12:39 +0000
        Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 10:45 -0800
    Re: Effective uses of c `goto' statement Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-04 19:35 +0100
    Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-04 19:49 -0500
      Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-04 20:52 -0500
        Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 02:19 +0000
          Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 01:43 -0800
          Re: Effective uses of c `goto' statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-05 02:00 -0800
            Re: Effective uses of c `goto' statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-05 02:01 -0800
            Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 22:45 +0000
              Re: Effective uses of c `goto' statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-11 19:33 -0800
                Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:12 +0000
          Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-05 12:49 +0000
            Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 22:42 +0000
              Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 05:46 -0800
              Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-06 14:16 +0000
                Re: Effective uses of c `goto' statement Öö Tiib <ootiib@hot.ee> - 2020-12-06 06:54 -0800
                  Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-06 16:19 +0000
                    Re: Effective uses of c `goto' statement Öö Tiib <ootiib@hot.ee> - 2020-12-06 15:34 -0800
                      Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-06 23:56 +0000
                        Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 11:11 +0100
                          Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-07 11:41 +0000
                            Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 15:35 +0100
                              Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-07 15:48 +0000
                            Re: Effective uses of c `goto' statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-07 11:46 -0800
                              Re: Effective uses of c `goto' statement Bart <bc@freeuk.com> - 2020-12-07 20:01 +0000
                                Re: Effective uses of c `goto' statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-07 13:03 -0800
                      Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 11:01 +0100
                        Re: Effective uses of c `goto' statement Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 03:35 -0800
                          Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-07 07:33 -0500
                            Re: Effective uses of c `goto' statement gazelle@shell.xmission.com (Kenny McCormack) - 2020-12-07 13:11 +0000
                            Re: Effective uses of c `goto' statement Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 05:24 -0800
                              Re: Effective uses of c `goto' statement Richard Damon <Richard@Damon-Family.org> - 2020-12-07 08:58 -0500
                                Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 15:48 +0100
                              Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 15:45 +0100
                                Re: Effective uses of c `goto' statement Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 07:29 -0800
                            Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 22:34 +0000
                          Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 15:38 +0100
            Re: Effective uses of c `goto' statement kegs@provalid.com (Kent Dickey) - 2020-12-10 15:45 -0600
          Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-07 21:43 +0000
            Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 23:02 +0000
              Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-10 21:15 +0000
                Re: Effective uses of c `goto' statement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:48 +0000
                  Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-11 20:59 +0000
                    Re: Effective uses of c `goto' statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-11 14:07 -0800
        Re: Effective uses of c `goto' statement Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-05 08:55 +0100
        Re: Effective uses of c `goto' statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 02:04 -0800
        Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-07 21:37 +0000
          Re: Effective uses of c `goto' statement James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-07 17:03 -0500
            Re: Effective uses of c `goto' statement David Brown <david.brown@hesbynett.no> - 2020-12-07 23:17 +0100
          Re: Effective uses of c `goto' statement Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-07 22:19 +0000
            Re: Effective uses of c `goto' statement Vir Campestris <vir.campestris@invalid.invalid> - 2020-12-10 21:13 +0000
        Re: Effective uses of c `goto' statement kegs@provalid.com (Kent Dickey) - 2020-12-10 15:30 -0600
    Re: Effective uses of c `goto' statement "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-12-05 13:01 -0500
    Re: Effective uses of c `goto' statement luser droog <luser.droog@gmail.com> - 2020-12-11 19:27 -0800

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#156861 — Effective uses of c `goto' statement

Hello C hackers/masters. :-)

  A lot of C textbooks say not to use `goto' statement,
but the fact is I find lots of Unix/Linux
C code often use `goto' statement.

  My question is how to effectively use `goto' statement with C code,
how to use `goto' to jump forward and jump back,
how to avoid multiple `goto' statements with both jump forward and jump
backward in the same function from messing up?

--
kevin

[toc] | [next] | [standalone]

#156862

kevin shell <kevin@fedora.osfans.org> writes:
> Hello C hackers/masters. :-)
>
>   A lot of C textbooks say not to use `goto' statement,
> but the fact is I find lots of Unix/Linux
> C code often use `goto' statement.
>
>   My question is how to effectively use `goto' statement with C code,
> how to use `goto' to jump forward and jump back,
> how to avoid multiple `goto' statements with both jump forward and jump
> backward in the same function from messing up?

Here's something I wrote about goto statements several years ago:

https://softwareengineering.stackexchange.com/a/133523/33478

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#156868

kevin shell:

> Hello C hackers/masters. :-)

Not me...

> A lot of C textbooks say not to use `goto' statement, but
> the fact is I find lots of Unix/Linux C code often use
> `goto' statement.

Of course, and Linux Torvalds himself explains it:

   https://web.archive.org/web/20171017142915/http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/

> My question is how to effectively use `goto' statement
> with C code, how to use `goto' to jump forward and jump
> back, how to avoid multiple `goto' statements with both
> jump forward and jump backward in the same function from
> messing up?

I never jump upwards and use forward `goto' statements

  1.  to handle stack-like resource deallocation,
  2.  to handle errors, and
  3.  as a general means of early bail-out.

They are very efficient in reducing indentation, which is
one of the Seven pillars of readable code:

   https://web.archive.org/web/20160517045517/http://www.perforce.com/resources/seven-pillars-pretty-code

I always strive to reduce the average level of indentation.
My rule is to test for the shortest branch and bail out,
e.g. instead of

   if( a )
   {  /* some   */
      /* lagrge */
      /* piece  */
      /* of     */
      /* code   */
   }
   else
   {  report_error();  }

I write:

   if( !a )
   {  report_error();
      goto Done;
   }
   /* some   */
   /* lagrge */
   /* piece  */
   /* of     */
   /* code   */
   Done:

When inside a loop, use `continue', e.g. instead of

   for( i = 0; i < n; i += 1 )
   {  if( a )
      {  /* large */
         /* block */
         /*   A   */
         if( b )
         {  /* large */
            /* block */
            /*   B   */
         }
         else
         {  error1();  }
      }
      else
      {  error2();  }
   }

write:

   for( i = 0; i < n; i += 1 )
   {  if( !a )
      {  error2();
         continue;
      }
      /* large */
      /* block */
      /*   A   */
      if( !b )
      {  error2();
         continue;
      }
      /* large */
      /* block */
      /*   B   */
   }

-- the idea is to flatten long linearly structured
conditions, so that adding another condition (large block C
and error3()) shall not increase indentation.

For handling errors, see my comments to Ned Batchelder's
articles about exceptions:

   https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#156870

I wrote:

> I always strive to reduce the average level of
> indentation.

That said, the mean or another estimate of indentaion level
is a new metric of code readability. Or do any existing
tools already use it?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#156873

On 02/12/2020 18:18, Anton Shepelev wrote:
> kevin shell:
> 
>> Hello C hackers/masters. :-)
> 
> Not me...
> 
>> A lot of C textbooks say not to use `goto' statement, but
>> the fact is I find lots of Unix/Linux C code often use
>> `goto' statement.

Don't use a "goto" unless it really makes the code better (clearer,
simpler, easier to maintain).  But if it /does/ make the code better,
use it.

"goto" is often considered "evil" because it breaks the block structure
of the language.  But is not so much the "goto" itself that is evil - it
is that "goto" can easily be misused, and give code that is hard to follow.

There are some cases where "goto" is commonly viewed as reasonable (such
as for error handling, and for escaping from nested loops).  And -
without having any references or statistical evidence for this - my
impression is that it is a lot more common in older code than newer
code, or code written in an older style.  In particular, "goto" can
quickly get confusing when jumping into blocks with initialised local
variables (common in C99 and newer code, much less common in C90 code).
 And it is regularly used with older and weaker compilers, as it could
be more efficient than alternatives such as flag variables or splitting
code into multiple functions.

> 
> Of course, and Linux Torvalds himself explains it:
> 
>    https://web.archive.org/web/20171017142915/http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/
> 

/Linus/ Torvalds is a well-known and successful C programmer, who can be
considered an expert on many aspects of coding.  That does not mean he
is an expert on everything, and he has a coding style that is somewhat
stuck in the nineties.  Consistency of style in a project like the Linux
kernel is essential - that does not make it a style that should be
copied blindly for new projects.

>> My question is how to effectively use `goto' statement
>> with C code, how to use `goto' to jump forward and jump
>> back, how to avoid multiple `goto' statements with both
>> jump forward and jump backward in the same function from
>> messing up?
> 
> I never jump upwards and use forward `goto' statements
> 
>   1.  to handle stack-like resource deallocation,
>   2.  to handle errors, and
>   3.  as a general means of early bail-out.
> 
> They are very efficient in reducing indentation, which is
> one of the Seven pillars of readable code:
> 
>    https://web.archive.org/web/20160517045517/http://www.perforce.com/resources/seven-pillars-pretty-code


Early returns are often a perfectly good means for bailing out early, or
handling errors and deallocation.  Splitting up big functions into
smaller ones is very efficient at reducing indentation.  (That does not
mean they are always better than using "goto" - merely that "goto" is
not necessary and not always the clearest choice.)

> 
> I always strive to reduce the average level of indentation.

That is not a good aim, IMHO.  Strive to make the code clearest and
easiest to read.  Deep indentation is merely one aspect of unclear code
- jumps that are too long vertically are just as bad.

> My rule is to test for the shortest branch and bail out,
> e.g. instead of
> 
>    if( a )
>    {  /* some   */
>       /* lagrge */
>       /* piece  */
>       /* of     */
>       /* code   */
>    }
>    else
>    {  report_error();  }
> 
> I write:
> 
>    if( !a )
>    {  report_error();
>       goto Done;
>    }
>    /* some   */
>    /* lagrge */
>    /* piece  */
>    /* of     */
>    /* code   */
>    Done:
> 

How about:

	if (!a) {
		report_error();
	} else {
		// Some large piece of code
	}

or:

	if (!a) {
		report_error();
		return;
	}
	// Some large piece of code


Or separate the functions:

static void foo(void) {
	// Some large piece of code
}

void bar(void) {
	if (a) {
		foo();
	} else {
		report_error();
	}
}


Without more context, I can't see any benefit from "goto" in that example.


> When inside a loop, use `continue', e.g. instead of
> 
>    for( i = 0; i < n; i += 1 )
>    {  if( a )
>       {  /* large */
>          /* block */
>          /*   A   */
>          if( b )
>          {  /* large */
>             /* block */
>             /*   B   */
>          }
>          else
>          {  error1();  }
>       }
>       else
>       {  error2();  }
>    }
> 
> write:
> 
>    for( i = 0; i < n; i += 1 )
>    {  if( !a )
>       {  error2();
>          continue;
>       }
>       /* large */
>       /* block */
>       /*   A   */
>       if( !b )
>       {  error2();
>          continue;
>       }
>       /* large */
>       /* block */
>       /*   B   */
>    }
> 
> -- the idea is to flatten long linearly structured
> conditions, so that adding another condition (large block C
> and error3()) shall not increase indentation.
> 

Again, you are (IMHO) optimising for the wrong thing here.  Put your
"large blocks" in separate functions.

> For handling errors, see my comments to Ned Batchelder's
> articles about exceptions:
> 
>    https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239
> 

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

#156876

On 2020-12-02, David Brown <david.brown@hesbynett.no> wrote:
> On 02/12/2020 18:18, Anton Shepelev wrote:
>> kevin shell:
>> 
>>> Hello C hackers/masters. :-)
>> 
>> Not me...
>> 
>>> A lot of C textbooks say not to use `goto' statement, but
>>> the fact is I find lots of Unix/Linux C code often use
>>> `goto' statement.
>
> Don't use a "goto" unless it really makes the code better (clearer,
> simpler, easier to maintain).  But if it /does/ make the code better,
> use it.

I'm afraid that a rule of this form is not very useful. The reason is
that it is logically covered by the following blanket rule:

"Don't change a single damn thing, unless it makes the code better."

That rule generates any special case you want:

- Don't use for, if, while, do, switch, return, ... unless it makes
the code better.

- Don't assign to anything unless it makes the code clearer.
Use pure functional programming as much as possible.

- Don't put code into a separate function unless it makes the code
better.

- Likewise, don't remove a function and convert calls to it into open
code unless that makes the code clearer.

- Don't add comments, unless it makes the code clearer.

- Likewise, don't remove comments, if that makes the code clearer.

- Don't write in C at all; use Python unless C is better.

Basically, a coding convention just needs that one blanket rule,
and the rest of it is concerned with a detailed definition of what
constitutes "better".

If the document says "not using goto is better than using goto",
then obviously the rule "don't change a single damn thing unless
it makes the code better" has the interpretation that a change which
introduces goto is to be rejected.

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

#156878

On 02/12/2020 20:35, Kaz Kylheku wrote:
> On 2020-12-02, David Brown <david.brown@hesbynett.no> wrote:
>> On 02/12/2020 18:18, Anton Shepelev wrote:
>>> kevin shell:
>>> 
>>>> Hello C hackers/masters. :-)
>>> 
>>> Not me...
>>> 
>>>> A lot of C textbooks say not to use `goto' statement, but the
>>>> fact is I find lots of Unix/Linux C code often use `goto'
>>>> statement.
>> 
>> Don't use a "goto" unless it really makes the code better
>> (clearer, simpler, easier to maintain).  But if it /does/ make the
>> code better, use it.
> 
> I'm afraid that a rule of this form is not very useful. The reason
> is that it is logically covered by the following blanket rule:
> 
> "Don't change a single damn thing, unless it makes the code better."
> 

Yes, agreed.  In other words, "goto" is not special and should not be
viewed either as something to use every chance, or something to avoid at
all costs.  The details in any coding standard are just to spell out
exactly what is meant by "making the code better", since that is
obviously a rather subjective phrase.

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

#156871

On 02/12/2020 08:42, kevin shell wrote:
>    My question is how to effectively use `goto' statement with C code,
> how to use `goto' to jump forward and jump back,
> how to avoid multiple `goto' statements with both jump forward and jump
> backward in the same function from messing up?

I try to avoid goto, and I can usually get away with it.

But then, I'm usually writing C++ :}

What the Linux kernel does is:
- Initialise all resources to an empty state
- Start doing the processing. If anything goes wrong set an error code 
and goto a cleanup label
- If everything goes right the "error" code is OK. Fall through to the label
- clean up all the resources you've acquired in the function in one place.

I don't recall seeing any _backwards_ goto-s in kernel code. Certainly 
there aren't many. The ones I've seen are acting as exceptions.

(In C++ you just allocate the resources as you go, and return whenever 
you want to. The compiler then cleans them up when they go out of scope 
- so long as they are stored in the correct way)

Andy

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

#156874

On 02/12/2020 19:07, Vir Campestris wrote:
> On 02/12/2020 08:42, kevin shell wrote:
>>    My question is how to effectively use `goto' statement with C code,
>> how to use `goto' to jump forward and jump back,
>> how to avoid multiple `goto' statements with both jump forward and jump
>> backward in the same function from messing up?
> 
> I try to avoid goto, and I can usually get away with it.
> 
> But then, I'm usually writing C++ :}
> 
> What the Linux kernel does is:
> - Initialise all resources to an empty state
> - Start doing the processing. If anything goes wrong set an error code
> and goto a cleanup label
> - If everything goes right the "error" code is OK. Fall through to the
> label
> - clean up all the resources you've acquired in the function in one place.
> 
> I don't recall seeing any _backwards_ goto-s in kernel code. Certainly
> there aren't many. The ones I've seen are acting as exceptions.
> 
> (In C++ you just allocate the resources as you go, and return whenever
> you want to. The compiler then cleans them up when they go out of scope
> - so long as they are stored in the correct way)
> 

Note that in C++, you don't need exceptions to get this effect - you do
it by having constructors and destructors in your classes, and simply
exiting the function, such as by an early return when there is an error.

(This is for the benefit of people less familiar with C++ - I'm sure
you, Vir, know this.)

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

#156872

In article <87czzszjhs.fsf@fedora.osfans.org>,
 kevin shell <kevin@fedora.osfans.org> wrote:

>   My question is how to effectively use `goto' statement with C code,

Finite automata are easily implemented using gotos.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#156880

On 2020-12-02, Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <87czzszjhs.fsf@fedora.osfans.org>,
>  kevin shell <kevin@fedora.osfans.org> wrote:
>
>>   My question is how to effectively use `goto' statement with C code,
>
> Finite automata are easily implemented using gotos.

Finite automata re easily implemented without goto, but only goto
offers the most efficient possible representation with the fewest
state variables (possibly with no state variable at all).

So for instance this trivial state machine (with no inputs, just
unconditional transitions, for simplicity):

   int state = 0;

   while (state != -1) {
     switch (state) {
     case 0:
        putchar('F');
        state = 1;
        break;
     case 1: case 2:
        putchar('O');
        state++;
        break;
     case 3:
        putchar('\n');
        state = -1;
        break;
     }
   }

can be rewritten without the state variable:

  goto S0:

  S2:
    putchar('O');
    goto S3;

  S1:
    putchar('O');
    goto S2;

  S3:
    putchar('\n');
    goto DONE;

  S0:
    putchar('F');
    goto S1:

  DONE:;

(Not to mention that we can just write it as a sequence of putchar
statements, which is beside the point.)

We've lost the convenience of collapsing states 1 and 2; I threw
that in to show that state variables can carry semantics, so eliminating
them is not always a pure benefit.

-- 
TXR Programming Language: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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

#156881

On 02/12/2020 21:18, Kaz Kylheku wrote:

> 
> We've lost the convenience of collapsing states 1 and 2; I threw
> that in to show that state variables can carry semantics, so eliminating
> them is not always a pure benefit.
> 

What benefit do you think there might be from eliminating state
variables at all?

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

#156886

On 2020-12-02, David Brown <david.brown@hesbynett.no> wrote:
> On 02/12/2020 21:18, Kaz Kylheku wrote:
>
>> 
>> We've lost the convenience of collapsing states 1 and 2; I threw
>> that in to show that state variables can carry semantics, so eliminating
>> them is not always a pure benefit.
>
> What benefit do you think there might be from eliminating state
> variables at all?

One is execution speed: code making fewer run-time checks on which it has to
branch. If we have goto in the language, we have a way to implement
certain situations ideally.

The other is simplicity.

So that is to say, the fact that we need to introduce state variables in
order to eliminate goto contributes an argument that elmination of goto
is not always simplification.

There are aspects of a goto that can make the control flow harder to
understand, but there are aspecs of a new state variable which can
also do that.

In a state machine, specifically, the state variable serves like
an additional instruction pointer. When we make an assignment like state =
42, the purpose of is to make he machine "go to" that state on
its next iteration, which has the effect of branching to the
corresponding code. The loop we have built around that switch is like a
fetch-decode-execute cycle; which exists on top of the one we are
already running.

This not only doesn't eliminate the complexity of goto, but adds
overhead.

-- 
TXR Programming Language: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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

#156890

On 03/12/2020 02:31, Kaz Kylheku wrote:
> On 2020-12-02, David Brown <david.brown@hesbynett.no> wrote:
>> On 02/12/2020 21:18, Kaz Kylheku wrote:
>>
>>>
>>> We've lost the convenience of collapsing states 1 and 2; I threw
>>> that in to show that state variables can carry semantics, so eliminating
>>> them is not always a pure benefit.
>>
>> What benefit do you think there might be from eliminating state
>> variables at all?
> 
> One is execution speed: code making fewer run-time checks on which it has to
> branch. If we have goto in the language, we have a way to implement
> certain situations ideally.
> 

I thought that might be your suggestion.  It is, however, not true for
modern optimising compilers.  Local state variables, flag variables,
etc., are often entirely "free" - if the compiler can turn these into a
set of jumps, it often will.  There are no guarantees, of course, and
sometimes a little care in your choice of setup can make a difference.

(It's a different matter for older, weaker compilers on limited
microcontrollers - if you are thinking of state machines on an 8051 or
COP8, then eliminating state variables can sometimes have efficiency
benefits.)

But in real cases, the "cost" of having a state variable is usually
utterly negligible.  In your example, the call to "putchar" will take
thousands of times more time than setting or checking "state".

Re-arranging code to remove state variables in the name of efficiency is
almost never appropriate.


> The other is simplicity.
> 

If avoiding state variables makes the code /simpler/, on the other hand,
then go for it.

> So that is to say, the fact that we need to introduce state variables in
> order to eliminate goto contributes an argument that elmination of goto
> is not always simplification.
> 
> There are aspects of a goto that can make the control flow harder to
> understand, but there are aspecs of a new state variable which can
> also do that.
> 

Agreed - there are no general "right" answers here.  (But sometimes
there are clearer /wrong/ answers, such as removing state variables in
the name of efficiency.)

> In a state machine, specifically, the state variable serves like
> an additional instruction pointer. When we make an assignment like state =
> 42, the purpose of is to make he machine "go to" that state on
> its next iteration, which has the effect of branching to the
> corresponding code. The loop we have built around that switch is like a
> fetch-decode-execute cycle; which exists on top of the one we are
> already running.
> 
> This not only doesn't eliminate the complexity of goto, but adds
> overhead.
> 

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

#156891

In article <rqa4nh$mlv$1@dont-email.me>,
 David Brown <david.brown@hesbynett.no> wrote:

> But in real cases, the "cost" of having a state variable is usually

A state variable is label variable and a switch is an assigned 
goto in a light disguise.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#156898

On 2020-12-03, David Brown <david.brown@hesbynett.no> wrote:
> On 03/12/2020 02:31, Kaz Kylheku wrote:
>> On 2020-12-02, David Brown <david.brown@hesbynett.no> wrote:
>>> On 02/12/2020 21:18, Kaz Kylheku wrote:
>>>
>>>>
>>>> We've lost the convenience of collapsing states 1 and 2; I threw
>>>> that in to show that state variables can carry semantics, so eliminating
>>>> them is not always a pure benefit.
>>>
>>> What benefit do you think there might be from eliminating state
>>> variables at all?
>> 
>> One is execution speed: code making fewer run-time checks on which it has to
>> branch. If we have goto in the language, we have a way to implement
>> certain situations ideally.
>> 
>
> I thought that might be your suggestion.  It is, however, not true for
> modern optimising compilers.  Local state variables, flag variables,
> etc., are often entirely "free" - if the compiler can turn these into a
> set of jumps, it often will.

So it's like you're having a conversation with the optimizer
through an somewhat impoverished language that doesn't have the exact
control construct you want, and are at the same time you're avoiding goto.

You cob together the control structure with an available control
consruct and a state variable. The optimizer infers what you're doing,
gives you a knowing wink, and pumps out the goto you really wanted,
eliminating the state variable.

:)

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

#156895

> One is execution speed: code making fewer run-time checks on which it has
> to branch. If we have goto in the language, we have a way to implement
> certain situations ideally.

If you break out of the switch-statement with having set the switch
-variable to a known state, the whole switching is optimized away
and the compiler does the same you would do with gotos manually.

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

#156944

Kaz Kylheku <563-365-8930@kylheku.com> writes:

[...]

> Finite automata re easily implemented without goto, but only goto
> offers the most efficient possible representation with the fewest
> state variables (possibly with no state variable at all).

Unless you can offer some sort of argument supporting this
assertion, I'm inclined to believe it is not the case.

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

#156952

On 12/5/20 11:28 AM, Tim Rentsch wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
> 
> [...]
> 
>> Finite automata re easily implemented without goto, but only goto
>> offers the most efficient possible representation with the fewest
>> state variables (possibly with no state variable at all).
> 
> Unless you can offer some sort of argument supporting this
> assertion, I'm inclined to believe it is not the case.
> 

Well, you can build the Finite automata where the state you are in is
the last label you did a 'goto' to (with an optimization that if it is
the next lable, the goto can be implied). That basically eliminates the
state variable (maybe some state works better in a state variable if you
have a series of states that are similar and just use a counter).

The non-goto method is typically a switch statement based on the state
variable, all in a while loop. There each state changes the variable and
breaks from the switch, and then loops in the while to go to the next state.

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

#156972

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/5/20 11:28 AM, Tim Rentsch wrote:
>
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>
>> [...]
>>
>>> Finite automata re easily implemented without goto, but only goto
>>> offers the most efficient possible representation with the fewest
>>> state variables (possibly with no state variable at all).
>>
>> Unless you can offer some sort of argument supporting this
>> assertion, I'm inclined to believe it is not the case.
>
> Well, you can build the Finite automata where the state you are in
> is the last label you did a 'goto' to (with an optimization that if
> it is the next lable, the goto can be implied).  That basically
> eliminates the state variable (maybe some state works better in a
> state variable if you have a series of states that are similar and
> just use a counter).

Yes, I understood that already.

> The non-goto method is typically a switch statement based on the
> state variable, all in a while loop.  There each state changes the
> variable and breaks from the switch, and then loops in the while to
> go to the next state.

A common way to implement a state machine is with a switch()
inside a loop of some sort (e.g., for() or while()).  I got that
already also.

My question is about other possibilities that do not use goto
but also do not use state variables.

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web