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

#157202

kegs@provalid.com (Kent Dickey) writes:

> 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.  [elaboration]

It's nice to hear someone finds merit in my suggestion.  :)

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

#156921

>    To jump forward, use "if", "switch", "return", or "break".

goto is sometimes the better solution.

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

#156924

On 12/4/20 9:20 AM, Stefan Ram wrote:
> kevin shell <kevin@fedora.osfans.org> writes:
>>  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?
> 
>   To jump forward, use "if", "switch", "return", or "break".
>   To jump backward, use "while", "for", "continue", or "do".
> 
> 

This only works if the target is at a point compatible with one of
these, it isn't always, or the use of ifs will create a lot of
indentation when using the goto to move forward to near the end of the
function to perform the needed cleanup of resources already allocated.

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

#156926

On 12/4/20 8:15 PM, Stefan Ram wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> This only works if the target is at a point compatible with one of
>> these, it isn't always,
> 
>   It worked for me so far (I'm not a professional programmer,
>   however, but an amateur programmer and a freelance instructor
>   for programming languages). 
> 
>   Maybe someone can show a compiling piece of code with
>   "goto"s, and I might then try and convert it to my style
>   (if I can find the time, maybe only in some weeks or so).
> 
>>                        or the use of ifs will create a lot of
>> indentation when using the goto to move forward to near the end of the
>> function to perform the needed cleanup of resources already allocated.
> 
>   When one has a lot of indentation, the function definition
>   is too large. (I can show how to meaningfully extract sub-
>   functions, which will reduce indentation if someone would
>   care to submit a compiling piece of code - if I can find 
>   the time, maybe only in some weeks or so).
> 
>   When would I use "goto"? When I have to translate a piece of
>   code from some other language to C or have to integrate a
>   piece of C code and do not have the time to carefully remove
>   the "goto"s, I'd rather leave the "goto"s in the code than
>   to introduce bugs by hastily trying to remove them.
> 

When using the goto to jump to the resource cleanup at the end of the
function, changing those to ifs adds a level for each resource that
needs to be gotten. If you have 4 resources, at an indent of 4, is 16
characters, or 25% of the 'typical' 80 character line. If the 'meat' of
the function uses a couple more, that can be excessive.

It also means that adding or removing a resource for the operation
(moving a buffer from an array on the stack to being malloced) now
changes the indent of the whole program, which plays badly with many
source control systems.

Yes, there are 'tricks' that can undo most of that extra indentation, by
adding state variables, and a lot of extra ifs, but they often make the
code look less clean.

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

#156928

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

> On 12/4/20 8:15 PM, Stefan Ram wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> This only works if the target is at a point compatible with one of
>>> these, it isn't always,
>> 
>>   It worked for me so far (I'm not a professional programmer,
>>   however, but an amateur programmer and a freelance instructor
>>   for programming languages). 
>> 
>>   Maybe someone can show a compiling piece of code with
>>   "goto"s, and I might then try and convert it to my style
>>   (if I can find the time, maybe only in some weeks or so).
>> 
>>>                        or the use of ifs will create a lot of
>>> indentation when using the goto to move forward to near the end of the
>>> function to perform the needed cleanup of resources already allocated.
>> 
>>   When one has a lot of indentation, the function definition
>>   is too large. (I can show how to meaningfully extract sub-
>>   functions, which will reduce indentation if someone would
>>   care to submit a compiling piece of code - if I can find 
>>   the time, maybe only in some weeks or so).
>> 
>>   When would I use "goto"? When I have to translate a piece of
>>   code from some other language to C or have to integrate a
>>   piece of C code and do not have the time to carefully remove
>>   the "goto"s, I'd rather leave the "goto"s in the code than
>>   to introduce bugs by hastily trying to remove them.
>> 
>
> When using the goto to jump to the resource cleanup at the end of the
> function, changing those to ifs adds a level for each resource that
> needs to be gotten. If you have 4 resources, at an indent of 4, is 16
> characters, or 25% of the 'typical' 80 character line. If the 'meat' of
> the function uses a couple more, that can be excessive.

Not necessarily; that's an overly general claim:

  char *buffer = 0, *workspace = 0;
  FILE *fp = 0;

  // get what we need...
  if ((buffer    = malloc(2*SIZE))     &&
      (workspace = malloc(SIZE))       &&
      (fp        = fopen(fname, "r"))) {
        // meat of the function...
  }

  // cleanup...
  free(buffer);
  free(workspace);
  if (fp) fclose(fp);

Depending on the situation, one might even get away with

  char *buffer    = malloc(2*SIZE),
       *workspace = malloc(SIZE);
  FILE *fp        = fopen(fname, "r");

  if (buffer && workspace && fp) {
      // meat of the function...
  }

  // cleanup...
  free(buffer);
  free(workspace);
  if (fp) fclose(fp);

There's been a lot of talk about code looking "clean", but I like code
to be easy to reason about, and goto can seriously mess that up.

-- 
Ben.

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

#156932

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 12/4/20 8:15 PM, Stefan Ram wrote:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> This only works if the target is at a point compatible with one of
>>>> these, it isn't always,
>>>
>>>   It worked for me so far (I'm not a professional programmer,
>>>   however, but an amateur programmer and a freelance instructor
>>>   for programming languages).
>>>
>>>   Maybe someone can show a compiling piece of code with
>>>   "goto"s, and I might then try and convert it to my style
>>>   (if I can find the time, maybe only in some weeks or so).
>>>
>>>>                        or the use of ifs will create a lot of
>>>> indentation when using the goto to move forward to near the end of the
>>>> function to perform the needed cleanup of resources already allocated.
>>>
>>>   When one has a lot of indentation, the function definition
>>>   is too large.  (I can show how to meaningfully extract sub-
>>>   functions, which will reduce indentation if someone would
>>>   care to submit a compiling piece of code - if I can find
>>>   the time, maybe only in some weeks or so).
>>>
>>>   When would I use "goto"?  When I have to translate a piece of
>>>   code from some other language to C or have to integrate a
>>>   piece of C code and do not have the time to carefully remove
>>>   the "goto"s, I'd rather leave the "goto"s in the code than
>>>   to introduce bugs by hastily trying to remove them.
>>
>> When using the goto to jump to the resource cleanup at the end of the
>> function, changing those to ifs adds a level for each resource that
>> needs to be gotten.  If you have 4 resources, at an indent of 4, is 16
>> characters, or 25% of the 'typical' 80 character line.  If the 'meat' of
>> the function uses a couple more, that can be excessive.
>
> Not necessarily;  that's an overly general claim:  [...]
>
>   char *buffer    = malloc(2*SIZE),
>        *workspace = malloc(SIZE);
>   FILE *fp        = fopen(fname, "r");
>
>   if (buffer && workspace && fp) {
>       // meat of the function...
>   }
>
>   // cleanup...
>   free(buffer);
>   free(workspace);
>   if (fp) fclose(fp);

+1

> There's been a lot of talk about code looking "clean", but I like code
> to be easy to reason about, and goto can seriously mess that up.

+1

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

#156933

On 12/4/2020 6:19 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> On 12/4/20 8:15 PM, Stefan Ram wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>> This only works if the target is at a point compatible with one of
>>>> these, it isn't always,
>>>
>>>    It worked for me so far (I'm not a professional programmer,
>>>    however, but an amateur programmer and a freelance instructor
>>>    for programming languages).
>>>
>>>    Maybe someone can show a compiling piece of code with
>>>    "goto"s, and I might then try and convert it to my style
>>>    (if I can find the time, maybe only in some weeks or so).
>>>
>>>>                         or the use of ifs will create a lot of
>>>> indentation when using the goto to move forward to near the end of the
>>>> function to perform the needed cleanup of resources already allocated.
>>>
>>>    When one has a lot of indentation, the function definition
>>>    is too large. (I can show how to meaningfully extract sub-
>>>    functions, which will reduce indentation if someone would
>>>    care to submit a compiling piece of code - if I can find
>>>    the time, maybe only in some weeks or so).
>>>
>>>    When would I use "goto"? When I have to translate a piece of
>>>    code from some other language to C or have to integrate a
>>>    piece of C code and do not have the time to carefully remove
>>>    the "goto"s, I'd rather leave the "goto"s in the code than
>>>    to introduce bugs by hastily trying to remove them.
>>>
>>
>> When using the goto to jump to the resource cleanup at the end of the
>> function, changing those to ifs adds a level for each resource that
>> needs to be gotten. If you have 4 resources, at an indent of 4, is 16
>> characters, or 25% of the 'typical' 80 character line. If the 'meat' of
>> the function uses a couple more, that can be excessive.
> 
> Not necessarily; that's an overly general claim:
> 
>    char *buffer = 0, *workspace = 0;
>    FILE *fp = 0;
> 
>    // get what we need...
>    if ((buffer    = malloc(2*SIZE))     &&
>        (workspace = malloc(SIZE))       &&
>        (fp        = fopen(fname, "r"))) {
>          // meat of the function...
>    }
> 
>    // cleanup...
>    free(buffer);
>    free(workspace);
>    if (fp) fclose(fp);
> 
> Depending on the situation, one might even get away with
> 
>    char *buffer    = malloc(2*SIZE),
>         *workspace = malloc(SIZE);
>    FILE *fp        = fopen(fname, "r");
> 
>    if (buffer && workspace && fp) {
>        // meat of the function...
>    }
> 
>    // cleanup...
>    free(buffer);
>    free(workspace);
>    if (fp) fclose(fp);


What about the return value of fclose? Like EINTR, EAGAIN, or ENOSPC?

> 
> There's been a lot of talk about code looking "clean", but I like code
> to be easy to reason about, and goto can seriously mess that up.
> 

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

#156934

On 12/5/2020 2:00 AM, Chris M. Thomasson wrote:
> On 12/4/2020 6:19 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 12/4/20 8:15 PM, Stefan Ram wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>> This only works if the target is at a point compatible with one of
>>>>> these, it isn't always,
>>>>
>>>>    It worked for me so far (I'm not a professional programmer,
>>>>    however, but an amateur programmer and a freelance instructor
>>>>    for programming languages).
>>>>
>>>>    Maybe someone can show a compiling piece of code with
>>>>    "goto"s, and I might then try and convert it to my style
>>>>    (if I can find the time, maybe only in some weeks or so).
>>>>
>>>>>                         or the use of ifs will create a lot of
>>>>> indentation when using the goto to move forward to near the end of the
>>>>> function to perform the needed cleanup of resources already allocated.
>>>>
>>>>    When one has a lot of indentation, the function definition
>>>>    is too large. (I can show how to meaningfully extract sub-
>>>>    functions, which will reduce indentation if someone would
>>>>    care to submit a compiling piece of code - if I can find
>>>>    the time, maybe only in some weeks or so).
>>>>
>>>>    When would I use "goto"? When I have to translate a piece of
>>>>    code from some other language to C or have to integrate a
>>>>    piece of C code and do not have the time to carefully remove
>>>>    the "goto"s, I'd rather leave the "goto"s in the code than
>>>>    to introduce bugs by hastily trying to remove them.
>>>>
>>>
>>> When using the goto to jump to the resource cleanup at the end of the
>>> function, changing those to ifs adds a level for each resource that
>>> needs to be gotten. If you have 4 resources, at an indent of 4, is 16
>>> characters, or 25% of the 'typical' 80 character line. If the 'meat' of
>>> the function uses a couple more, that can be excessive.
>>
>> Not necessarily; that's an overly general claim:
>>
>>    char *buffer = 0, *workspace = 0;
>>    FILE *fp = 0;
>>
>>    // get what we need...
>>    if ((buffer    = malloc(2*SIZE))     &&
>>        (workspace = malloc(SIZE))       &&
>>        (fp        = fopen(fname, "r"))) {
>>          // meat of the function...
>>    }
>>
>>    // cleanup...
>>    free(buffer);
>>    free(workspace);
>>    if (fp) fclose(fp);
>>
>> Depending on the situation, one might even get away with
>>
>>    char *buffer    = malloc(2*SIZE),
>>         *workspace = malloc(SIZE);
>>    FILE *fp        = fopen(fname, "r");
>>
>>    if (buffer && workspace && fp) {
>>        // meat of the function...
>>    }
>>
>>    // cleanup...
>>    free(buffer);
>>    free(workspace);
>>    if (fp) fclose(fp);
> 
> 
> What about the return value of fclose? Like EINTR, EAGAIN, or ENOSPC?

Wrt EOF and errno?

> 
>>
>> There's been a lot of talk about code looking "clean", but I like code
>> to be easy to reason about, and goto can seriously mess that up.
>>
> 

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

#156966

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 12/4/2020 6:19 PM, Ben Bacarisse wrote:
<cut>
>>    // cleanup...
>>    free(buffer);
>>    free(workspace);
>>    if (fp) fclose(fp);
>
> What about the return value of fclose?

Yes, that should be checked in many cases, but I don't think that alters
the goto/no goto comparison.

-- 
Ben.

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

#157219

On 12/5/2020 2:45 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 12/4/2020 6:19 PM, Ben Bacarisse wrote:
> <cut>
>>>     // cleanup...
>>>     free(buffer);
>>>     free(workspace);
>>>     if (fp) fclose(fp);
>>
>> What about the return value of fclose?
> 
> Yes, that should be checked in many cases, but I don't think that alters
> the goto/no goto comparison.


Might add more error handling state.

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

#157231

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 12/5/2020 2:45 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 12/4/2020 6:19 PM, Ben Bacarisse wrote:
>> <cut>
>>>>     // cleanup...
>>>>     free(buffer);
>>>>     free(workspace);
>>>>     if (fp) fclose(fp);
>>>
>>> What about the return value of fclose?
>>
>> Yes, that should be checked in many cases, but I don't think that alters
>> the goto/no goto comparison.
>
> Might add more error handling state.

I don't follow.  Maybe you could give an example where checking fclose
would tip the balance one way or the other?

-- 
Ben.

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

#156940

On 05/12/2020 02:19, Ben Bacarisse wrote:

> There's been a lot of talk about code looking "clean", but I like code
> to be easy to reason about, and goto can seriously mess that up.
> 

Not using goto can mess it up too, if it means lots more code, more 
identation and more logic.

Take this switch-case:

     switch (a) {
     case 10:
         puts("ten");
         break;
     case 20:
         puts("twenty");
         break;
     default:
         puts("other");
     }

This a pattern of code I use a lot, but frequently, I want to execute 
the body of case 10 followed by that of 20. Or sometimes part of case 
20, followed by part of case 10.

These will be simple bits of code that are not worth putting into 
separate functions.

The following is a more specific pattern that for me occurs over and 
over again (the switch-cases and if-else chains or nested switch-case 
are usually much longer):

     switch (a) {
     case 10:
         if (a)
         else if (b)
         else
             <error handling code>
         break;
     case 20
         if (c)
            if (x) <error handling code>
         else if (d)
         else
             <error handling code>
         break;
     default:
         <error handling code>
     }

The error code is the same in each case (and can use locals so is not 
practical to off-load to a function) This statement is not the last 
thing in a function, so it is not cleanup code at the end of a function 
like the other examples in the thread.

What is the simplest solution in C?

(Although 'default:' looks like a label, C doesn't allow 'goto default' 
which would have been one tidy answer, and you will know that label can 
only be the one in this switch-statement.)

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

#156965

Bart <bc@freeuk.com> writes:

> On 05/12/2020 02:19, Ben Bacarisse wrote:
>
>> There's been a lot of talk about code looking "clean", but I like code
>> to be easy to reason about, and goto can seriously mess that up.
>>
>
> Not using goto can mess it up too, if it means lots more code, more
> identation and more logic.

Maybe.  I'm always looking for good examples.

> Take this switch-case:
>
>     switch (a) {
>     case 10:
>         puts("ten");
>         break;
>     case 20:
>         puts("twenty");
>         break;
>     default:
>         puts("other");
>     }
>
> This a pattern of code I use a lot, but frequently, I want to execute
> the body of case 10 followed by that of 20. Or sometimes part of case
> 20, followed by part of case 10.

But this is not real code with a real purpose.  It's possible that these
requirements stem from some earlier design decisions that may not have
been optimal.  This is what I was saying before -- the simplest solution
/from here/ is not necessarily the best overall.  Good code rarely
results from many locally optimal changes.

> These will be simple bits of code that are not worth putting into
> separate functions.

What is your criterion for that?  I've written functions as simple as

  double square(double x) { return x * x; }

I like functions.  A lot.

> The following is a more specific pattern that for me occurs over and
> over again (the switch-cases and if-else chains or nested switch-case
> are usually much longer):
>
>     switch (a) {
>     case 10:
>         if (a)
>         else if (b)
>         else
>             <error handling code>
>         break;
>     case 20
>         if (c)
>            if (x) <error handling code>
>         else if (d)
>         else
>             <error handling code>
>         break;
>     default:
>         <error handling code>
>     }

There are too many unknowns here to be sure what the best design is.

> The error code is the same in each case (and can use locals so is not
> practical to off-load to a function) This statement is not the last
> thing in a function, so it is not cleanup code at the end of a
> function like the other examples in the thread.
>
> What is the simplest solution in C?

There's no way to know.  Do you have a real function with a well-defined
purpose that I could look at?

-- 
Ben.

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

#156974

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:

[...]

>> These will be simple bits of code that are not worth putting into
>> separate functions.
>
> What is your criterion for that?  I've written functions as simple as
>
>   double square(double x) { return x * x; }
>
> I like functions.  A lot.

Ditto and double ditto.

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

#156980

On 05/12/2020 22:42, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 

>> These will be simple bits of code that are not worth putting into
>> separate functions.
> 
> What is your criterion for that?

For creating a small function rather than repeating code:

* To provide useful abstraction

* When the functionality could be useful from many places especially 
across functions and modules

* To provide one point of maintenance, and one point of reference

* When such functions can form a suite of related tasks

* When the interface to the function is simple and clean


For me those don't apply when:

* The task is simply to avoid duplication of code within the same function.

* When that code are of no relevance outside this function (I wouldn't 
use local functions for this)

* When the same thing might need to be done with 100 functions, which 
would then need 100 auxiliary functions, all polluting the module name space

* When the interface to the function would be messy (and inefficient, 
important to me as I like using private compilers with not that great 
code generation)

* When I want to keep the code local rather than hidden away somewhere 
else, both for readability, and to simplify maintenance


I tend not to use local functions (they're not guaranteed in C, and I 
may drop them in my own languages as I simply never use them).

I did play with a feature to share such code within a function, but it 
resembled Basic's GOSUB, so I decided not to pursue it. (But I might 
have a rethink.)



   I've written functions as simple as
> 
>    double square(double x) { return x * x; }
> 
> I like functions.  A lot.

Other people like files a lot. Some are fond of directories too.

For me nothing is more exasperating than a program split up into 
hundreds of tiny files each of which just gives a key-hole view of the 
program. And worse when spread across multiple directories (eg most 
github projects I look at).

But lots of tiny functions created for no good reason comes close.

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

#156983

On Sunday, 6 December 2020 at 16:17:07 UTC+2, Bart wrote:
> On 05/12/2020 22:42, Ben Bacarisse wrote:
> > I've written functions as simple as 
> > 
> > double square(double x) { return x * x; } 
> > 
> > I like functions. A lot.
> Other people like files a lot. Some are fond of directories too. 

Some people like some things that you do not like. That is
normal as everybody do not like same things.

> For me nothing is more exasperating than a program split up into 
> hundreds of tiny files each of which just gives a key-hole view of the 
> program. And worse when spread across multiple directories (eg most 
> github projects I look at).

You like to look at things that are most exasperating to you? Why?
Look at things that you like, that inspire you.

> But lots of tiny functions created for no good reason comes close.

Said function was perhaps made for one can write "square(a - b)" 
instead  of "(a - b) * (a - b)". What is so criminal about it?
How it annoys you?

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

#156985

On 06/12/2020 14:54, Öö Tiib wrote:
> On Sunday, 6 December 2020 at 16:17:07 UTC+2, Bart wrote:

>> But lots of tiny functions created for no good reason comes close.
> 
> Said function was perhaps made for one can write "square(a - b)"
> instead  of "(a - b) * (a - b)". What is so criminal about it?
> How it annoys you?


Did you read my post? I listed reasons for creating small functions, and 
reasons for not creating them.

Creating a mathematical function such as square would probably go into 
the first list. Partly because it would not be relevant to that one 
function where it is used.

(However, in C that specific one would probably be better off as a 
macro. Such functions I would prefer to be properly overloaded, and not 
have the possible extra overheads of a function call either.

In my languages, 'sqr' is an overloaded operator.)

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

#156999

On Sunday, 6 December 2020 at 18:19:46 UTC+2, Bart wrote:
> On 06/12/2020 14:54, Öö Tiib wrote: 
> > On Sunday, 6 December 2020 at 16:17:07 UTC+2, Bart wrote: 
> 
> >> But lots of tiny functions created for no good reason comes close. 
> > 
> > Said function was perhaps made for one can write "square(a - b)" 
> > instead of "(a - b) * (a - b)". What is so criminal about it? 
> > How it annoys you?
> Did you read my post? I listed reasons for creating small functions, and 
> reasons for not creating them. 

Yes I did. As answer to example of that square(x) you did tell how
you hate files and directories the most and then that such short
functions come close. It wasn't transparent to me that you did
talk about some other kind of functions than to what you were
replying and whose examples no one brought, sorry.

> Creating a mathematical function such as square would probably go into 
> the first list. Partly because it would not be relevant to that one 
> function where it is used. 
> 
> (However, in C that specific one would probably be better off as a 
> macro. Such functions I would prefer to be properly overloaded, and not 
> have the possible extra overheads of a function call either. 

Wouldn't such macro square(foo(x)) call foo(x) twice? That can
lose in efficiency or even cause hard to notice defects
when that foo has side effects. Meanwhile modern compilers
tend to inline such short functions. The gcc does it even link time
with -flto option.

> In my languages, 'sqr' is an overloaded operator.)

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

#157002

On 06/12/2020 23:34, Öö Tiib wrote:
> On Sunday, 6 December 2020 at 18:19:46 UTC+2, Bart wrote:
>> On 06/12/2020 14:54, Öö Tiib wrote:
>>> On Sunday, 6 December 2020 at 16:17:07 UTC+2, Bart wrote:
>>
>>>> But lots of tiny functions created for no good reason comes close.
>>>
>>> Said function was perhaps made for one can write "square(a - b)"
>>> instead of "(a - b) * (a - b)". What is so criminal about it?
>>> How it annoys you?
>> Did you read my post? I listed reasons for creating small functions, and
>> reasons for not creating them.
> 
> Yes I did. As answer to example of that square(x) you did tell how
> you hate files and directories the most and then that such short
> functions come close. It wasn't transparent to me that you did
> talk about some other kind of functions than to what you were
> replying and whose examples no one brought, sorry.

I said "But lots of tiny functions created for no good reason comes close."

The 'no good reason' bit is important!

>> Creating a mathematical function such as square would probably go into
>> the first list. Partly because it would not be relevant to that one
>> function where it is used.
>>
>> (However, in C that specific one would probably be better off as a
>> macro. Such functions I would prefer to be properly overloaded, and not
>> have the possible extra overheads of a function call either.
> 
> Wouldn't such macro square(foo(x)) call foo(x) twice? That can
> lose in efficiency or even cause hard to notice defects
> when that foo has side effects. Meanwhile modern compilers
> tend to inline such short functions. The gcc does it even link time
> with -flto option.

Yes, no, maybe! This is the usual story with C:

* Macros may evaluate their arguments twice, problematic if that causes 
extra side-efects.

* You can create type-specific versions, with a local temporary, but you 
lose the advantage of being type-agnostic

* You can implement it via a function, but it may or may not inline it, 
or if it is extern, LTO may not be available to inline it.

* Even inside a function, it you to use with int arguments, it may end 
up doing a floating point operation. (gcc-O3 does so even with the 
function local.)

So, nothing is really guaranteed.

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

#157016

On 07/12/2020 00:56, Bart wrote:
> On 06/12/2020 23:34, Öö Tiib wrote:
>> On Sunday, 6 December 2020 at 18:19:46 UTC+2, Bart wrote:
>>> On 06/12/2020 14:54, Öö Tiib wrote:
>>>> On Sunday, 6 December 2020 at 16:17:07 UTC+2, Bart wrote:
>>>
>>>>> But lots of tiny functions created for no good reason comes close.
>>>>
>>>> Said function was perhaps made for one can write "square(a - b)"
>>>> instead of "(a - b) * (a - b)". What is so criminal about it?
>>>> How it annoys you?
>>> Did you read my post? I listed reasons for creating small functions, and
>>> reasons for not creating them.
>>
>> Yes I did. As answer to example of that square(x) you did tell how
>> you hate files and directories the most and then that such short
>> functions come close. It wasn't transparent to me that you did
>> talk about some other kind of functions than to what you were
>> replying and whose examples no one brought, sorry.
> 
> I said "But lots of tiny functions created for no good reason comes close."
> 
> The 'no good reason' bit is important!
> 
>>> Creating a mathematical function such as square would probably go into
>>> the first list. Partly because it would not be relevant to that one
>>> function where it is used.
>>>
>>> (However, in C that specific one would probably be better off as a
>>> macro. Such functions I would prefer to be properly overloaded, and not
>>> have the possible extra overheads of a function call either.
>>
>> Wouldn't such macro square(foo(x)) call foo(x) twice? That can
>> lose in efficiency or even cause hard to notice defects
>> when that foo has side effects. Meanwhile modern compilers
>> tend to inline such short functions. The gcc does it even link time
>> with -flto option.
> 
> Yes, no, maybe! This is the usual story with C:

Eh, no.  "I don't understand C, but like to exaggerate and spread FUD!"
- this is the usual story with Bart.

The rules are simple.  People might use the language in unclear ways,
but the language itself is clear.  Macros are simple text substitution.

> 
> * Macros may evaluate their arguments twice, problematic if that causes
> extra side-efects.

This isn't news to anyone who has the slightest understanding and
experience of the language.  And it is not hard to handle.  Sometimes it
is an inconvenience - no language is ideal in all cases.  (And no
language - including yours - protects users from bad programmers who
write confusing code.)

> 
> * You can create type-specific versions, with a local temporary, but you
> lose the advantage of being type-agnostic
> 

That would be inline functions, not function-like macros.  (Unless you
are allowing gcc extensions, in which case other extensions solve all
your problems here.)  And yes, that's a limitation of C.  It's not
unclear, or confusing, or mixed-up - it's just a limitation of the language.

> * You can implement it via a function, but it may or may not inline it,
> or if it is extern, LTO may not be available to inline it.

The compiler will inline it if it makes a difference to the speed.  (If
the compiler can't inline such simple functions, you are probably using
the wrong compiler - certainly you are not going to get efficient object
code no matter what you write.)

> 
> * Even inside a function, it you to use with int arguments, it may end
> up doing a floating point operation. (gcc-O3 does so even with the
> function local.)

I can't make sense of what you are trying to say here.  Post an example
that can be pasted into <https://godbolt.org>, and I will have a look.

> 
> So, nothing is really guaranteed.
> 

When you refuse to understand anything, and prefer to invent new ways to
get things wrong or confuse yourself, then you are right - for /you/,
nothing is guaranteed.  Other C programmers don't have the same issues.

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

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

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

csiph-web