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

Started bykevin shell <kevin@fedora.osfans.org>
First post2020-12-02 16:42 +0800
Last post2020-12-11 19:27 -0800
Articles 20 on this page of 114 — 24 participants

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


#156975

FromRichard Damon <Richard@Damon-Family.org>
Date2020-12-06 08:51 -0500
Message-ID<ml5zH.56199$hg2.7498@fx20.iad>
In reply to#156972
On 12/6/20 8:03 AM, Tim Rentsch wrote:
> 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.
> 

I think the key is that the state needs to be stored somehow. It can be
explicitly in a variable, or implicitly in the processor address, but it
needs to be somewhere.

It could perhaps be also done in functions that return the address of
the function that is the next state, and that address is directly called
and not saved so no 'state variable' every really existed.

The tricky part here is that in C you can not define a function of the
self-referenctial type of a function that returns a pointer to a
function of its type, so it needs to return a different type of function
pointer that is casts to its type and then called.

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


#156976

FromRichard Damon <Richard@Damon-Family.org>
Date2020-12-06 08:56 -0500
Message-ID<qq5zH.176759$sW6.28293@fx47.iad>
In reply to#156975
On 12/6/20 8:51 AM, Richard Damon wrote:
> On 12/6/20 8:03 AM, Tim Rentsch wrote:
>> 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.
>>
> 
> I think the key is that the state needs to be stored somehow. It can be
> explicitly in a variable, or implicitly in the processor address, but it
> needs to be somewhere.
> 
> It could perhaps be also done in functions that return the address of
> the function that is the next state, and that address is directly called
> and not saved so no 'state variable' every really existed.
> 
> The tricky part here is that in C you can not define a function of the
> self-referenctial type of a function that returns a pointer to a
> function of its type, so it needs to return a different type of function
> pointer that is casts to its type and then called.
> 

Thinking a bit more, this only supports a finite (and fairly limited)
number of transitions, you will need to store the address of the next
function and loop and that creates the 'state variable'

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


#157009

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-06 18:43 -0800
Message-ID<86zh2qibea.fsf@linuxsc.com>
In reply to#156975
Richard Damon <Richard@Damon-Family.org> writes:

> On 12/6/20 8:03 AM, Tim Rentsch wrote:
>
>> 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.
>
> I think the key is that the state needs to be stored somehow.  It
> can be explicitly in a variable, or implicitly in the processor
> address, but it needs to be somewhere.

Yes, no doubt about that.

> It could perhaps be also done in functions that return the address
> of the function that is the next state, and that address is directly
> called and not saved so no 'state variable' every really existed.

Not in its usual sense, for sure.  Written in a simple way, we
might see something like this:

    SomeSortOfFunction f = ...;
    while(  f  )  f = f( &fsm_data );

> The tricky part here is that in C you can not define a function of
> the self-referenctial type of a function that returns a pointer to a
> function of its type, so it needs to return a different type of
> function pointer that is casts to its type and then called.

We can't define a type in C that is directly recursive, but we
can achieve a similar effect using structs and pointers:

    struct function_returning_itself_s;
    typedef struct function_returning_itself_s *FtoF;

    typedef struct function_returning_itself_s {
        FtoF (*it)( long * );
    } FtoF_object[1];

    FtoF
    wits_end( long *data ){
        static FtoF_object me = {{ wits_end }};
        if(  !data  )  return  0;
        return  me;
    }

    void
    run_fsm( FtoF f, long *data ){
        while(  f  )  f = f->it( data );
    }

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


#156977

FromÖö Tiib <ootiib@hot.ee>
Date2020-12-06 05:58 -0800
Message-ID<20fe6a37-9bbd-41d1-a7d2-bc02df8707e8n@googlegroups.com>
In reply to#156972
On Sunday, 6 December 2020 at 15:03:18 UTC+2, Tim Rentsch wrote:
> Richard Damon <Ric...@Damon-Family.org> writes: 
> 
> > On 12/5/20 11:28 AM, Tim Rentsch wrote: 
> > 
> >> Kaz Kylheku <563-36...@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.

I know of only one in C that is function pointer. It is technically also
state variable. 

Downside of state handler function pointer is that whatever the
machine processes and whatever it produces has to be passed
between those  functions and compilers can't optimize it much.

Upside is that those functions feel easier to maintain and to
reason about that that long switch or the goto spaghetti.
Also it can be invoked directly so gets rid of said switch
whatsoever but that wasn't anyway present on case of gotos.

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


#157007

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-06 16:54 -0800
Message-ID<864kkyjv0y.fsf@linuxsc.com>
In reply to#156977
Öö Tiib <ootiib@hot.ee> writes:

> On Sunday, 6 December 2020 at 15:03:18 UTC+2, Tim Rentsch wrote:
>
>> Richard Damon <Ric...@Damon-Family.org> writes:
>>
>>> On 12/5/20 11:28 AM, Tim Rentsch wrote:
>>>
>>>> Kaz Kylheku <563-36...@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.
>
> I know of only one in C that is function pointer.  It is
> technically also state variable.  [...]

Certainly any data item that is used to represent the state of an
FSM and is stored in a variable may reasonably be called a state
variable.

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


#156956

FromSiri Cruise <chine.bleu@yahoo.com>
Date2020-12-05 10:01 -0800
Message-ID<chine.bleu-B93846.10014405122020@reader.eternal-september.org>
In reply to#156944
In article <86sg8kkyjb.fsf@linuxsc.com>,
 Tim Rentsch <tr.17687@z991.linuxsc.com> 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.

    #define moore(state) state:
    #define next(predicate,state) if (predicate) goto state;
    #define shift curr = fgetc(stdin);
    #define append if (n+1>=m) \
                buffer = realloc(buffer, m=2*(n+1)); \
            buffer[n++] = curr; buffer[n] = 0;
    #define final(string, token) yylval = string; return token;
    static int curr = 0;  char *buffer = 0; int m = 0, n = 0;
    moore(start) if (curr==0) shift
        next(isalpha(curr), identifier)
        next(curr=='_', identifier)
        next(curr=='0', zero)
        next(isdigit(curr), integer)
        next(curr=='"', string)
        next(curr=='\'', literal)
        ...
    moore(identifier) append shift
        next(isalpha(curr), identifier)
        next(curr=='_', identifier)
        next(isdigit(curr), identifier)
        next(true, endidentifier)
    moore(endidentifier) final(buffer, IDEN)
    moore(zero) shift
        next(curr=='x', hexidecimalx)
        next(curr=='X', hexidecimalx)
        next(curr=='8', endzero)
        next(curr=='9', endzero)
        next(isdigit(curr), octal)
        next(true, endzero)
    moore(endzero) final("0", ZERO)
    moore(hexidecimalx) shift
        next(isxdigit(curr), hexidecimal)
        next(true, endzero)
    moore(hexidecimal) append shift
        next(isxdigit(curr), hexidecimal)
        next(true, endhexidecimal)
    moore(endhexidecimal)
        asprintf(&buffer, "%llu", strtoull(buffer, 0, 16));
        next(true, integertype)
    moore(octal) append shift
        next(curr=='8', endoctal)
        next(curr=='9', endoctal)
        next(isdigit(curr), octal)
        next(true, integertype)
    moore(endoctal)
        asprintf(&buffer, "%llu", strtoull(buffer, 0, 8));
        next(true, endinteger)
    moore(integer) append shift
        next(isdigit(integer), integer)
        next(curr=='.', real)
        next(curr=='e', real)
        next(curr=='E', real)
        next(true, integertype)
    moore(integertype)
        next(curr=='L', integerl);
        next(curr=='U', integeru);
        next(true, endinteger)
    moore(endinteger) final(buffer, INTEGER)
    moore(integerl) shift
        next(curr=='L', integerll);
        next(curr=='U', integerlu);
        next(true, endintegerl)
    moore(endintegerl) final(buffer, LINTEGER)
    moore(integerll) shift
        next(curr=='U', endintegerllu);
        next(true, endintegerll)
    moore(endintegerll) final(buffer, LLINTEGER)
    moore(integeru) shift
        next(curr=='L', integerlu);
        next(true, endintegeru)
    moore(endintegeru) final(buffer, UINTEGER)
    moore(integerlu) shift
        next(curr=='L', endintegerllu);
        next(true, endintegerlu)
    moore(endintegerlu) final(buffer, LUINTEGER)
    moore(endintegerllu) shift final(buffer, LLUINTEGER)
...

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


#156971

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-06 04:55 -0800
Message-ID<86k0tvksau.fsf@linuxsc.com>
In reply to#156956
Siri Cruise <chine.bleu@yahoo.com> writes:

> In article <86sg8kkyjb.fsf@linuxsc.com>,
>  Tim Rentsch <tr.17687@z991.linuxsc.com> 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.
>
> [...C code for a state machine implemented with goto's...]

My question is about the part of the assertion after "but".

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


#156904

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-03 21:20 -0800
Message-ID<86zh2um9jk.fsf@linuxsc.com>
In reply to#156872
Siri Cruise <chine.bleu@yahoo.com> writes:

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

It is also true that finite automata are easily implemented
without using gotos.

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


#156905

FromSiri Cruise <chine.bleu@yahoo.com>
Date2020-12-03 21:50 -0800
Message-ID<chine.bleu-23EBBF.21502203122020@reader.eternal-september.org>
In reply to#156904
In article <86zh2um9jk.fsf@linuxsc.com>,
 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Siri Cruise <chine.bleu@yahoo.com> writes:
> 
> > 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.
> 
> It is also true that finite automata are easily implemented
> without using gotos.

They're gotos in a lite masquerade.

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


#156907

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-03 23:06 -0800
Message-ID<86r1o6m4nw.fsf@linuxsc.com>
In reply to#156905
Siri Cruise <chine.bleu@yahoo.com> writes:

> In article <86zh2um9jk.fsf@linuxsc.com>,
>  Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Siri Cruise <chine.bleu@yahoo.com> writes:
>>
>>> 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.
>>
>> It is also true that finite automata are easily implemented
>> without using gotos.
>
> They're gotos in a lite masquerade.

Question:  if you call a tail a leg, how many legs does
a dog have?

Answer:  four.  Calling a tail a leg doesn't make it one.

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


#156910

FromSiri Cruise <chine.bleu@yahoo.com>
Date2020-12-04 00:27 -0800
Message-ID<chine.bleu-C5F0D4.00270804122020@reader.eternal-september.org>
In reply to#156907
In article <86r1o6m4nw.fsf@linuxsc.com>,
 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Question:  if you call a tail a leg, how many legs does
> a dog have?

Three.

https://www.hillspet.com/dog-care/new-pet-parent/adopting-three-le
gged-pets

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


#156875

Fromfoo <opaquefoo@gmail.com>
Date2020-12-02 11:03 -0800
Message-ID<4b4afd50-5d40-4bd0-abe2-0c7ab3f11397n@googlegroups.com>
In reply to#156861
среда, 2 декабря 2020 г. в 15:43:13 UTC+7, kevin shell:
> 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

By the way, here is another possible solution with error handling (I don't know 
how portable it is):

http://fdiv.net/2015/10/08/emulating-defer-c-clang-or-gccblocks

Very similar to destructors in C ++.

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


#156877

FromDavid Brown <david.brown@hesbynett.no>
Date2020-12-02 21:02 +0100
Message-ID<rq8rsi$j4f$1@dont-email.me>
In reply to#156875
On 02/12/2020 20:03, foo wrote:
> среда, 2 декабря 2020 г. в 15:43:13 UTC+7, kevin shell:
>> 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
> 
> By the way, here is another possible solution with error handling (I don't know 
> how portable it is):
> 
> http://fdiv.net/2015/10/08/emulating-defer-c-clang-or-gccblocks
> 
> Very similar to destructors in C ++.
> 

This is not going to be very portable because it depends on clang or a
special build of gcc (Apple's private build, used only on Macs AFAIK).
Here is a slightly better choice that will work with any gcc, since it
uses nested functions (a gcc extension since forever) rather than blocks
(an Apple-only concept in C).  It's still non-portable beyond gcc and
clang, and I'm not suggesting it's a great way to structure your code -
but it /is/ a possible way to do it.

Let's start with a pair of resource acquire / release functions.  I've
added an extra parameter to "release" just to make it a little less
simple (so that you can't just use "release" by itself as the cleanup
function - which would work for malloc/free).

extern int * get(void);
extern void release(int *, int r);

extern int bar(int * a, int * b);	// Do the "real" work


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;
}


Here is the code with a cleanup macro:

#define PASTE1(t1, t2) t1 ## t2
#define PASTE2(t1, t2) PASTE1(t1, t2)
#define CLEANUP(func, ...) \
    void PASTE2(cleanup, __LINE__) (int **p) { \
        if (*p) func(*p, ## __VA_ARGS__); } \
    __attribute__((cleanup(PASTE2(cleanup, __LINE__))))


int foo_cleanup(void) {
    CLEANUP(release, 10) int * a = get();
    if (!a) return -1;

    CLEANUP(release, 20) int * b = get();
    if (!b) return -2;

    int x = bar(a, b);

    return x;
}


A quick test with <https://godbolt.org> shows these generate the same
code with optimisation enabled, bar cosmetic details.

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


#156936

FromÖö Tiib <ootiib@hot.ee>
Date2020-12-05 03:04 -0800
Message-ID<4c0e5eea-0c51-48fc-bb65-553af8171b62n@googlegroups.com>
In reply to#156877
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:

> int foo_else(void) {
>     int x;
> 
>     int * a = get();
>     if (!a) x = -1; else {
>         
>         int * b = get();
>         if (!b) x = -2; else {
>             
>             x = bar(a, b);
>             release(b, 20);
>         }
>         release(a, 10);
>     }
>     return x;
> } 

That logic feels easier for me as indentation indicates 
where else jumps. 

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


#156938

FromÖö Tiib <ootiib@hot.ee>
Date2020-12-05 03:36 -0800
Message-ID<5584a32b-3343-45de-8999-974a08a7bee5n@googlegroups.com>
In reply to#156936
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: 
> > int foo_else(void) { 
> > int x; 
> > 
> > int * a = get(); 
> > if (!a) x = -1; else { 
> > 
> > int * b = get(); 
> > if (!b) x = -2; else { 
> > 
> > x = bar(a, b); 

Swap next two lines.

> > release(b, 20); 
> > } 

Swap next two lines.

> > release(a, 10); 
> > } 
> > return x; 
> > } 
> 
> That logic feels easier for me as indentation indicates 
> where else jumps.

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

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


#156939 — Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2020-12-05 11:45 +0000
SubjectGood thing this isn't a Python group (Was: Effective uses of c `goto' statement)
Message-ID<rqfrtg$3n5hr$1@news.xmission.com>
In reply to#156938
In article <5584a32b-3343-45de-8999-974a08a7bee5n@googlegroups.com>,
  Tiib  <ootiib@hot.ee> wrote:
...
>Seems that new google groups removes indentation so if I want it
>I can't post from whatever device to Usenet anymore. :(

I wonder what they do in the Python groups...

-- 
I'm building a wall.

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


#156942 — Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)

FromDavid Brown <david.brown@hesbynett.no>
Date2020-12-05 14:38 +0100
SubjectRe: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)
Message-ID<rqg2fu$dci$2@dont-email.me>
In reply to#156939
On 05/12/2020 12:45, Kenny McCormack wrote:
> In article <5584a32b-3343-45de-8999-974a08a7bee5n@googlegroups.com>,
>   Tiib  <ootiib@hot.ee> wrote:
> ...
>> Seems that new google groups removes indentation so if I want it
>> I can't post from whatever device to Usenet anymore. :(
> 
> I wonder what they do in the Python groups...
> 

I gather Python's Benevolent Dictator For Life has recently left Google
and joined Microsoft.  I'm sure there's a conspiracy theory lurking in
there somewhere...

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


#156969 — Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2020-12-06 11:00 +0000
SubjectRe: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)
Message-ID<slrnrspeen.2ptb.grahn+nntp@frailea.sa.invalid>
In reply to#156942
On Sat, 2020-12-05, David Brown wrote:
> On 05/12/2020 12:45, Kenny McCormack wrote:
>> In article <5584a32b-3343-45de-8999-974a08a7bee5n@googlegroups.com>,
>>   Tiib  <ootiib@hot.ee> wrote:
>> ...
>>> Seems that new google groups removes indentation so if I want it
>>> I can't post from whatever device to Usenet anymore. :(
>> 
>> I wonder what they do in the Python groups...
>> 
>
> 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/

Mentioning it only because of parallels to this thread.

> has recently left Google and joined Microsoft.  I'm sure there's a
> conspiracy theory lurking in there somewhere...

There's probably one about the BDFL thing, too ...

/Jorgen

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

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


#156970 — Re: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2020-12-06 12:33 +0000
SubjectRe: Good thing this isn't a Python group (Was: Effective uses of c `goto' statement)
Message-ID<rqij1u$3ogsh$1@news.xmission.com>
In reply to#156969
In article <slrnrspeen.2ptb.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Sat, 2020-12-05, David Brown wrote:
>> On 05/12/2020 12:45, Kenny McCormack wrote:
>>> In article <5584a32b-3343-45de-8999-974a08a7bee5n@googlegroups.com>,
>>>   Tiib  <ootiib@hot.ee> wrote:
>>> ...
>>>> Seems that new google groups removes indentation so if I want it
>>>> I can't post from whatever device to Usenet anymore. :(
>>> 
>>> I wonder what they do in the Python groups...
>>> 
>>
>> I gather Python's Benevolent Dictator For Life 
>
>He abdicated in 1998, after fights about new language features, e.g.

1998?  22 years ago?

-- 
The plural of "anecdote" is _not_ "data".

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


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

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2020-12-06 14:09 -0800
SubjectRe: Good thing this isn't a Python group
Message-ID<87h7oyfuyg.fsf@nosuchdomain.example.com>
In reply to#156969
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.

[...]

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


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

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


csiph-web