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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#157100 — Re: Good thing this isn't a Python group

On Sun, 2020-12-06, Keith Thompson wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Sat, 2020-12-05, David Brown wrote:
> [...]
>>> I gather Python's Benevolent Dictator For Life 
>>
>> He abdicated in 1998, after fights about new language features, e.g.
>>
>>   https://lwn.net/Articles/757713/
>
> It was 2018, not 1998.

Thanks.  1998 was some kind of typo, possibly Y2K-related.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#156941

On 05/12/2020 12:36, Öö Tiib wrote:
> On Saturday, 5 December 2020 at 13:04:59 UTC+2, Öö Tiib wrote:
>> On Wednesday, 2 December 2020 at 22:02:42 UTC+2, David Brown wrote: 
>>>
>>> Here is an example of code in the goto style: 
>>>
>>>
>>> int foo_goto(void) { 
>>> int x; 
>>>
>>> int * a = get(); 
>>> if (!a) { x = -1; goto exit1; } 
>>>
>>> int * b = get(); 
>>> if (!b) { x = -2; goto exit2; } 
>>>
>>> x = bar(a, b); 
>>>
>>> exit2: 
>>> release(b, 20); 
>>> exit1: 
>>> release(a, 10); 
>>>
>>> return x; 
>>> } 
>>
>> I do not perhaps understand something but that example seems to 
>> just replace elses with gotos. Why? Else is IMHO simpler. 
>> Here I edit your code into else style: 
>>
> 
> Oh I did not even notice that David's example releases a on every case
> even when it is null pointer.
> Unusual so maybe it was typo but I correct my code to be equivalent: 

It was a typo - or rather, misplaced labels.  (Sorry for that!)  I very
rarely use goto's like this, and prefer to combine if/else and
sub-functions.

Note that my "goto style" code was not written as an example of how I
think code should be written, but just to show the behaviour that can be
achieved with the gcc cleanup attribute for those that prefer it.

> 
> Seems that new google groups removes indentation so if I want it
> I can't post from whatever device to Usenet anymore. :(
> 

Yes, I've heard that GG have introduced some new ways of screwing things
up.  I believe there are proper Usenet clients for mobile devices, if
that's what you want (I can't type properly on them, but some people
seem to be able to live in them).

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

#156879

On 2020-12-02, kevin shell <kevin@fedora.osfans.org> wrote:
> 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.

Well, who wod you believe? People who write books, or people who
maintain a kernel?

All sorts of idiots have written completely awful books and gotten away
with it. Idiots, who could absolutely not contribute to a real project,
let alone something demanding like the kernel.
>
>   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 is some theory. First some background statements:

- A conditional goto is the most primitive control statement
  (in the imperative world of Fortran and Algol descendants;
  I'm not discussing continuations and such here.)

- All control structures like while, if and switch can be
  regarded as being based on goto or a jump able under the hood.

- The set of control structures is open: we have not invented all
  possible control structures, and the programming language we
  are discussing has only a small sample of the known control
  constructs which occur in programming languages.

Then we come to this important observation:

- Control structures sometimes require additional state variables in
  order to achieve a particular control flow.  If only goto is used, the
  sate variables can be eliminated.  What can also eliminate state
  variables is inventing a new control construct which fits the
  situation.

Case-in-point: breaking out of a loop.

Suppose we have a "while (expr) statement" loop.  How do we break early
out of a loop?

Solution 1: add a state variable:

  bool done = false;

  while (guard && !done) {
     ...
     if (condition)
        done = true;
  }

Solution 2: just use goto!

  while (guard) {
     ...
     if (condition)
        goto outl
  }

  out: ;

Solution 3: invent new control construct feature: break statement:

  while (guard) {
     ...
     if (condition)
        break;
  }

The break keyword is just goto in disguise.

If we don't have goto, there are situations where we may have to add
dummy state variables and checks in order to achieve the same control
transfers.

Knowledge about the trade-off with state variables can lead us to some
possibly useful coding rules:

1. Don't use goto if the problem can be solved with existing control
   structures without adding any dummy state variables at all.

2. Don't use goto if the problem can be solved with one clear dummy
   state variable, whose value is tested in no more than two places.

For good measure I would add:

3. Avoid backwards goto; put a loop around the code, with breaks
   (forward goto in disguise) in all the places that must not loop,
   so the backward jump takes place when the bottom of the loop is
   reached.

4. Do not introduce goto which skips over existing goto labels.

5. Do not introduce goto which skips over goto statements which
   do not go to the same label.

6. If independent gotos must cross each other, insist that they are
   cleanly nested:

     /* good */        /* bad */
     foo:              foo:
        ...               ...

     bar:              bar:
        ...               ...

        goto bar;         goto foo;
        ...               ....
        goto foo;         goto bar;

6. Do not introduce goto which jumps into blocks, such that
   their variable initializations are skipped (forbidden in C++).

Regarding 6: I would say, if possible within the project constraints,
write C that also compiles as C++. Fix any diagnostics related to goto
generated by the C++ compiler.

-- 
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]

#156896

Even MISRA:C 2012 accepts gotos in C when the gotos step forward.

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

#156901

On Wednesday, December 2, 2020 at 2:43:13 AM UTC-6, kevin shell wrote:
> 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. 

There are times when it's not the wrong answer, usually when breaking out
of a deeply nested loop.  
  
> 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? 
> 

My personal rules:

1. Branch forward *only* - never branch backwards;
2. Limit the scope of the goto - that is, minimize the distance from the
    goto statement to the label you're branching to;
3. Don't overlap scopes - that is, in the code between a goto and its
    label, there should *not* be another goto that branches to a 
    different label.
4. Never bypass the entry point of a control structure - that is, never
    branch into the body of an if, switch, for, while, or do-while statement;
5. Never use goto in place of a control structure which accomplishes
    the same thing.

About the only time I use a goto is to branch out of a deeply nested
loop, and that's only if I can't think of a better way to deal with 
the problem.  

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

#156902

On Thursday, 3 December 2020 at 23:41:08 UTC, jfbod...@gmail.com wrote:
> On Wednesday, December 2, 2020 at 2:43:13 AM UTC-6, kevin shell wrote: 
> > 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.
> There are times when it's not the wrong answer, usually when breaking out 
> of a deeply nested loop.
> > 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? 
> >
> My personal rules: 
> 
> 1. Branch forward *only* - never branch backwards; 
> 2. Limit the scope of the goto - that is, minimize the distance from the 
> goto statement to the label you're branching to; 
> 3. Don't overlap scopes - that is, in the code between a goto and its 
> label, there should *not* be another goto that branches to a 
> different label. 
> 4. Never bypass the entry point of a control structure - that is, never 
> branch into the body of an if, switch, for, while, or do-while statement; 
> 5. Never use goto in place of a control structure which accomplishes 
> the same thing. 
> 
> About the only time I use a goto is to branch out of a deeply nested 
> loop, and that's only if I can't think of a better way to deal with 
> the problem.
>
I use goto for error handling.

If we've got this pattern

/* dynamic arrays */
Employee *employees = 0;
char *somestring = 0;
int *somethingelse = 0;

we can fail to allocate memory for these arrays. That's likely fatal to the
calculation.
So put a test after each allocation call, and jump to error_exit;

employees = malloc( ... );
if (!employees)
   goto error_exit;

/* normal return, 0 indicates no error */
return 0;

/* error return. Clean up first. */
error_exit;
  free(employees);
  free(somestring);
  free(somethingelse):

  return -1;

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

#156911

"jfbod...@gmail.com" <jfbode1029@gmail.com> writes:

> On Wednesday, December 2, 2020 at 2:43:13 AM UTC-6, kevin shell wrote:
>> 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. 
>
> There are times when it's not the wrong answer, usually when breaking out
> of a deeply nested loop.  
>   
>> 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? 
>> 
>
> My personal rules:
>
> 1. Branch forward *only* - never branch backwards;

I think this advice is not practical,
I recently learned OpenBSD smtpd and
found quite lots of backward `goto'.

> 2. Limit the scope of the goto - that is, minimize the distance from the
>     goto statement to the label you're branching to;
> 3. Don't overlap scopes - that is, in the code between a goto and its
>     label, there should *not* be another goto that branches to a 
>     different label.
> 4. Never bypass the entry point of a control structure - that is, never
>     branch into the body of an if, switch, for, while, or do-while statement;
> 5. Never use goto in place of a control structure which accomplishes
>     the same thing.
>
Agreed. :-)

> About the only time I use a goto is to branch out of a deeply nested
> loop, and that's only if I can't think of a better way to deal with 
> the problem.  

This is only one often used case.

--
kevin

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

#156919

On Friday, December 4, 2020 at 2:30:05 AM UTC-6, kevin shell wrote:
> "jfbod...@gmail.com" <jfbod...@gmail.com> writes: 
> 
> > On Wednesday, December 2, 2020 at 2:43:13 AM UTC-6, kevin shell wrote: 
> >> 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. 
> > 
> > There are times when it's not the wrong answer, usually when breaking out 
> > of a deeply nested loop. 
> > 
> >> 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? 
> >> 
> > 
> > My personal rules: 
> > 
> > 1. Branch forward *only* - never branch backwards;
> I think this advice is not practical, 
> I recently learned OpenBSD smtpd and 
> found quite lots of backward `goto'.

Early in my career I dealt with some code that used goto as the primary
control structure, and it was a *mess*.  One of the things that made it
so nasty was branching backwards to re-execute some code that was part
of multiple different execution paths, so fixing a problem for one execution
path *inevitably* broke code in a different execution path.  The code was
so tightly coupled with itself that we literally could not make *any* changes
without breaking it.  

So yeah, that experience has colored my views on using goto, especially
with respect to backwards branching.  It's bad practice, full stop. 
Don't use it.  I don't care if smtpd uses it, I don't care if it's enshrined in 
all kinds of canonical *nix code, it's the equivalent of using gets()
in 2020.  Bad juju all the way around.  

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

#156920

On Friday, December 4, 2020 at 3:30:05 AM UTC-5, kevin shell wrote:
> "jfbod...@gmail.com" <jfbod...@gmail.com> writes: 
...
> > 1. Branch forward *only* - never branch backwards;
> I think this advice is not practical, 
> I recently learned OpenBSD smtpd and 
> found quite lots of backward `goto'.

There are many people who follow the practice of never using "goto", without much problem.
It can't be more of a problem to only allow only forward gotos.

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

#156912

On 03/12/2020 23:40, jfbod...@gmail.com wrote:
> On Wednesday, December 2, 2020 at 2:43:13 AM UTC-6, kevin shell wrote:
>> 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.
> 
> There are times when it's not the wrong answer, usually when breaking out
> of a deeply nested loop.
>    
>> 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?
>>
> 
> My personal rules:
> 
> 1. Branch forward *only* - never branch backwards;
> 2. Limit the scope of the goto - that is, minimize the distance from the
>      goto statement to the label you're branching to;
> 3. Don't overlap scopes - that is, in the code between a goto and its
>      label, there should *not* be another goto that branches to a
>      different label.
> 4. Never bypass the entry point of a control structure - that is, never
>      branch into the body of an if, switch, for, while, or do-while statement;
> 5. Never use goto in place of a control structure which accomplishes
>      the same thing.
> 
> About the only time I use a goto is to branch out of a deeply nested
> loop, and that's only if I can't think of a better way to deal with
> the problem.
> 

My personal rule is not to worry about it, and just to use goto when 
that's the simplest, easiest way to do something.

My incidence of goto usage in non-C code is perhaps once every 400 
lines. Function bodies are much smaller, so it doesn't happen often that 
there are multiple gotos crossing each other within the same function.

C lacks nested loop breaks, certain other loop controls, and the ability 
to break even one level out of a loop from inside a switch statement, so 
the incidence would be higher, if I wrote a lot of C.

But my generated C code may have double the incidence.

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

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

#156913

On Friday, 4 December 2020 at 11:19:46 UTC, Bart wrote:
>  
> But my generated C code may have double the incidence. 
> 
Lua is a scripting language which originally didn't have goto, 
on the grounds that it's harmful and can always be removed.

However as Lua caught on, people started wanting to generate 
it automatically. It was found that adding goto made the generators
much easier to write.

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

#156915

On 04/12/2020 12:35, Malcolm McLean wrote:
> On Friday, 4 December 2020 at 11:19:46 UTC, Bart wrote:
>>   
>> But my generated C code may have double the incidence.
>>
> Lua is a scripting language which originally didn't have goto,
> on the grounds that it's harmful and can always be removed.
> 
> However as Lua caught on, people started wanting to generate
> it automatically. It was found that adding goto made the generators
> much easier to write.
> 


I didn't know that, but apparently it's only on Lua 5.2 (I have version 
5.1.5 in a directory I call 'luanew'), so it sounds recent!

Some of the rationale for it is here:

http://lua-users.org/wiki/GotoStatement

Which includes:

"It may help readability for label names to indicate the direction (up 
or down) that they jump. [10] In the example below, it may be 
conventionally understood that the names continue and skip will jump 
down and the name redo will jump up.

-- 5.2.0-beta-rc2
::redo:: for x=1,10 do for y=1,10 do
   if not f(x,y) then goto continue end
   if not g(x,y) then goto skip end
   if not h(x,y) then goto redo end
   ::continue::
end end ::skip:: "

This is interesting for me as those are just the loop controls I build 
in to my own languages anyway, so that gotos are not needed there. (I 
call 'redo' 'restart'; my 'redo' repeats the iteration.)

It's good that some languages are recognisng the value of 'goto', it 
makes a change from removing features that many consider fundamental.

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

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

#156923

Bart <bc@freeuk.com> writes:
[...]
> I didn't know that, but apparently it's only on Lua 5.2 (I have
> version 5.1.5 in a directory I call 'luanew'), so it sounds recent!

5.1.5 is from 2012.
5.2   is from 2011.
The current version is 5.4.2.

-- 
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]

#156914

Bart <bc@freeuk.com> writes:

> My personal rule is not to worry about it, and just to use goto when
> that's the simplest, easiest way to do something.

As a rule to be adopted by others this is bordering on being reckless.
Not only is it a bad rule for using goto, it's a bad rule for using any
construct, and there is a real danger a novice programmer might
generalise it since there nothing goto-specific about it.

I've seen countless examples of buggy, messy code where I can imagine
that every step on the way there was the simplest, easiest option at the
time.

-- 
Ben.

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

#156916

On 04/12/2020 13:09, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> My personal rule is not to worry about it, and just to use goto when
>> that's the simplest, easiest way to do something.
> 
> As a rule to be adopted by others this is bordering on being reckless.
> Not only is it a bad rule for using goto, it's a bad rule for using any
> construct, and there is a real danger a novice programmer might
> generalise it since there nothing goto-specific about it.
> 
> I've seen countless examples of buggy, messy code where I can imagine
> that every step on the way there was the simplest, easiest option at the
> time.

I said this was my personal rule. I'm not a novice programmer, and my 
code is generally devoid of gotos** (even after writing considerable 
amounts of old Fortran and ASM in the past).

But I'm not afraid of using it, if there is no simpler solution. That 
means not writing convoluted code, or structuring it in unnatural ways, 
or introducing state variables and extra logic.

People can use their own criteria, and unless they have to follow 
certain guidelines, shouldn't worry too much about what others think.

Half the uses of goto in C will be because the language lacks certain 
control flow features. But while people are happy about overcoming such 
limitations with macros (which I consider worse than goto), gotos have a 
bad reputation.


(**My current language doesn't need the 'goto' keyword; you can just 
write L instead of 'goto L', but thats not what I mean by devoid!)

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

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

#156906

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?

I have a different kind of suggestion than some of the others you
have gotten.

Don't use goto's at all, under any circumstances.  If you see a
piece of code that has a goto in it, try to re-write it without
using goto, as clearly as you can.  You might try three or four
ways of writing a patch of code, and see which one(s) seem
easier to read or easier to understand.  Do this for a period
of three years (yes that is a serious suggestion).

Like many other aspects of writing, before you learn how and when
to bend or break the rules, it's important to learn how to follow
them.  Often a situation where goto seems natural means there is
something else more significantly wrong with the code in some
other way.  Being able to see and fix those other things is much
more important than learning a few rules about using goto.

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

#156922

> Don't use goto's at all, under any circumstances.  If you see a
> piece of code that has a goto in it, try to re-write it without
> using goto, as clearly as you can.  You might try three or four
> ways of writing a patch of code, and see which one(s) seem
> easier to read or easier to understand.  Do this for a period
> of three years (yes that is a serious suggestion).

There are sometimes good reasons for goto. The Linux-Kernel
uses gotos for resource-deallocation in a inverted order.
That's a more readable solution than a buch of nested ifs.
Even MISRA:C 2012 allows gotos if they go forward.

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

#156931

Bonita Montero <Bonita.Montero@gmail.com> writes:

[...]

Is there some reason you didn't answer my question in the thread
on "arranging items in a array with a sorted pointer-list"?
(At least I didn't see any answer.)

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

#157116

In article <86v9dim4td.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>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?
>
>I have a different kind of suggestion than some of the others you
>have gotten.
>
>Don't use goto's at all, under any circumstances.  If you see a
>piece of code that has a goto in it, try to re-write it without
>using goto, as clearly as you can.  You might try three or four
>ways of writing a patch of code, and see which one(s) seem
>easier to read or easier to understand.  Do this for a period
>of three years (yes that is a serious suggestion).
>
>Like many other aspects of writing, before you learn how and when
>to bend or break the rules, it's important to learn how to follow
>them.  Often a situation where goto seems natural means there is
>something else more significantly wrong with the code in some
>other way.  Being able to see and fix those other things is much
>more important than learning a few rules about using goto.

I agree with the above advice.  I think goto's are generally easy to avoid,
and I find most code using goto difficult to follow.  If you really
believe goto's are essential, try writing without them, and you'll probably
find a cleaner solution.  Or, you'll learn that goto is the true way and
you were right the whole time.

For example, Linux uses goto to handle situations like:

	ret = get_lock(&lock1);
	if(!ret) {
		goto finish;
	}
	ret = get_lock(&lock2);
	if(!ret) {
		goto release_lock1:
	}
	...

	release_lock(&lock2);
release_lock1:
	release_lock(&lock1);
finish:
	return something;

This is basically an idiom in Linux.  But goto is easy to remove and it
can make the code better.  You can:

1) Write get_2locks() which gets both locks, or none (by it freeing lock1
	if it is unable to also then get lock2).  Push the complexity to
	another simpler routine, which only needs to be written once.
2) Track current partial state that needs to be "undone" with a structure.
	At function end (or, better, in the caller function), undo all
	partial work.

Note there's more information available for consistency checks in either of
the above alternatives.  It's possible to check that all locks are obtained
in the proper order, and it's possible to basically ensure that if the
code compiles, then all temporary resources must be restored properly.

Kent

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

#157147

On 09/12/2020 06:23, Kent Dickey wrote:
> In article <86v9dim4td.fsf@linuxsc.com>,

>> Like many other aspects of writing, before you learn how and when
>> to bend or break the rules, it's important to learn how to follow
>> them.  Often a situation where goto seems natural means there is
>> something else more significantly wrong with the code in some
>> other way.  Being able to see and fix those other things is much
>> more important than learning a few rules about using goto.
> 
> I agree with the above advice.  I think goto's are generally easy to avoid,
> and I find most code using goto difficult to follow.  If you really
> believe goto's are essential, try writing without them, and you'll probably
> find a cleaner solution.  Or, you'll learn that goto is the true way and
> you were right the whole time.
> 
> For example, Linux uses goto to handle situations like:
> 
> 	ret = get_lock(&lock1);
> 	if(!ret) {
> 		goto finish;
> 	}
> 	ret = get_lock(&lock2);
> 	if(!ret) {
> 		goto release_lock1:
> 	}
> 	...
> 
> 	release_lock(&lock2);
> release_lock1:
> 	release_lock(&lock1);
> finish:
> 	return something;
> 
> This is basically an idiom in Linux.  But goto is easy to remove and it
> can make the code better.  You can:
> 
> 1) Write get_2locks() which gets both locks, or none (by it freeing lock1
> 	if it is unable to also then get lock2).  Push the complexity to
> 	another simpler routine, which only needs to be written once.
> 2) Track current partial state that needs to be "undone" with a structure.
> 	At function end (or, better, in the caller function), undo all
> 	partial work.


I think this is the wrong approach here. Basically you are rewriting the 
program, creating new functions which do different things.

That may not be practical or advisable in a large codebase such as the 
Linux kernel which is 20 million lines of code.

You should be able to reorganise code within a function, without 
changing anything outside it, or even understanding what those functions do.

Imagine your example was written like this:

     R = F(&A);
     if (!R) goto L2;
     R = F(&B);
     if (!R) goto L1;
     ....
     G(&B)
  L1:
     G(&A);
  L2:
     return X;

Now you can play with it as much as you like, provided the logic is 
maintained.

(I can see that goto can be trivially removed, at the cost of some code 
duplication, and introducing multiple return points, for example:

     R = F(&A);
     if (!R) return X;
     R = F(&B);
     if (!R) G(&A); return X;
     ....
     G(&B)
     G(&A);
     return X;

)

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

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

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

csiph-web