Author Topic: Discussion on state machines  (Read 2959 times)

0 Members and 1 Guest are viewing this topic.

Offline SiliconWizard

  • Frequent Contributor
  • **
  • Posts: 557
  • Country: fr
Re: Discussion on state machines
« Reply #25 on: May 17, 2018, 07:08:37 am »
I was told that the critical-safety development environment does not practically allow pointers to any functions. This is probably due to static code analysis.

I'd be interested in seeing this mentioned in any of the well known guidelines for safety-critical software (such as MISRA-C or some IECxxx or DOxxx standards). As I already mentioned, dynamic memory allocation is usually not recommended (or sometimes even banned), but function pointers? That doesn't ring a bell. But many companies have their own set of rules, and some even recommend against using pointers altogether. Of course this is all wishful thinking, and would make a middle-sized C project a real mess with global variables everywhere. Not pretty and unmaintainable. :palm:

Decent static analysis tools can infer a whole lot of things from the source code, even with function pointers. Very intricate designs that would be hard to do static analysis on can benefit from dynamic analysis tools, which are usually pretty expensive (LDRA has this kind of tools for instance), but very effective.
 

Offline Warhawk

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: 00
    • Personal resume
Re: Discussion on state machines
« Reply #26 on: May 17, 2018, 07:24:51 am »
What the heck is even "the critical-safety development environment"  :-//

Siwastaja, I am not a native English speaker. Neither you are (based on the flag). I was referring to firmware development for safety-critical applications.  ::)

As I mentioned in the first post - I do not program professionally. Embedded software is just my hobby and I am simply interested in different techniques, code snippets and patterns. This is the reason why I said "I was told..."  :-X I got this information from colleagues developing railway automation for a quite known German company with a green logo  8)

I wish Jack Ganssle joined the thread. Hearing his opinion and practical experience would be interesting.

Offline rhb

  • Super Contributor
  • ***
  • Posts: 1358
  • Country: us
Re: Discussion on state machines
« Reply #27 on: May 17, 2018, 07:34:53 am »
If all the pointers are initialized at compile time, I don't think there would be any issues.  Not to say it might not violate the rules some PHB declared.

From a practical perspective, why would one do anything other than initialize the table at compile time and declare it  CONST?  If you are really paranoid, keep a CONST copy of the table and reinitialize ii if the watchdog timer goes off.

OOP is just loads of tables of function pointers, one for each object. This is why xclock now has an 80 MB footprint in core.  Inheritance is just  named COMMON and GOTO with fresh lipstick.

A reading suggestion:

Safer C: Developing Software for High-integrity and Safety-critical Systems
Les Hatton
McGraw-Hill 1995

Les founded Programming Research Ltd which produces a line of static code analyzers.  Les has since left PRL, but has been active in safety critical code audits and such.
 

Offline Warhawk

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: 00
    • Personal resume
Re: Discussion on state machines
« Reply #28 on: May 17, 2018, 07:41:46 am »
Thanks for the tip.
I will just add the following link: https://www.misra.org.uk/forum/viewtopic.php?t=240

It seems that I may have been misinterpreting the "pointer to a function is a no-go" for years. I understand this that as long as the function pointer is const type, the world is safe.

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 4300
  • Country: us
Re: Discussion on state machines
« Reply #29 on: May 17, 2018, 09:56:59 am »
If all the pointers are initialized at compile time, I don't think there would be any issues.  Not to say it might not violate the rules some PHB declared.

From a practical perspective, why would one do anything other than initialize the table at compile time and declare it  CONST?  If you are really paranoid, keep a CONST copy of the table and reinitialize ii if the watchdog timer goes off.


For those CPUs executing code out of flash, the compiler will put the table in flash if it is declared CONST.  That pretty much prevents the possibility of a pointer getting changed.

If it isn't automatically placed in flash, it is possible to force the linker to put it there anyway.
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 1358
  • Country: us
Re: Discussion on state machines
« Reply #30 on: May 17, 2018, 10:35:36 am »
If all the pointers are initialized at compile time, I don't think there would be any issues.  Not to say it might not violate the rules some PHB declared.

From a practical perspective, why would one do anything other than initialize the table at compile time and declare it  CONST?  If you are really paranoid, keep a CONST copy of the table and reinitialize ii if the watchdog timer goes off.


For those CPUs executing code out of flash, the compiler will put the table in flash if it is declared CONST.  That pretty much prevents the possibility of a pointer getting changed.

If it isn't automatically placed in flash, it is possible to force the linker to put it there anyway.

An excellent point and one of the many reasons I prefer C for most things.  It's easy to understand the rules and what will actually happen.  Of course, for numerical work FORTRAN is better.  Lex, yacc, awk and MATLAB/Octave all have their places too.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 6991
  • Country: gb
    • Having fun doing more, with less
Re: Discussion on state machines
« Reply #31 on: May 17, 2018, 10:48:40 am »
An excellent point and one of the many reasons I prefer C for most things.  It's easy to understand the rules and what will actually happen.

Er, no. Or at least only at a superficial level.

As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.

Quote
Of course, for numerical work FORTRAN is better.  Lex, yacc, awk and MATLAB/Octave all have their places too.

Er, yes :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1535
  • Country: nz
Re: Discussion on state machines
« Reply #32 on: May 17, 2018, 11:16:11 am »
As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.

Regarding that article I agree with the first comment "This is an excellent troll and strawman argument.".

For those who don't want to take the time to read it, here is a summary:

Old computers supported C.
Modern computers all support C.
Modern computers are complex.
Modern computers have issues.

Therefore continued support for C is the cause of everything that is wrong with computers today (incl Specter & Meltdown).

(Author must be one of those functional programming types)
 
The following users thanked this post: nugglix

Offline ehughes

  • Frequent Contributor
  • **
  • Posts: 295
  • Country: us
Re: Discussion on state machines
« Reply #33 on: May 17, 2018, 01:17:48 pm »
I prefer switch/case for state machines.    The compiler will generally implement with jump table.     You ALWAYS have to trap the possibility of an invalid state so I generally find it cleaner than a function pointer table.     The minute you need logic for an invalid value for your state value, you might as well use a case structure.  There might be an esoteric method in C to trap invalid function pointers but I generally avoid the super elegant solutions.

     I always implement functions for transition logic.          I generally have 1 high level system state machine  with state machines for each individual process in the main loop.    I have tried just about every approach and this always seemed  to be the best low energy approximation to a good design.
 

Offline NorthGuy

  • Frequent Contributor
  • **
  • Posts: 860
  • Country: ca
Re: Discussion on state machines
« Reply #34 on: May 17, 2018, 02:06:52 pm »
You ALWAYS have to trap the possibility of an invalid state

Why? Unless you calculate your states, which is relatively rare, you assign the values directly or draw them from some sort of table. In either case, the probability of getting an invalid state is slim to none.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1535
  • Country: nz
Re: Discussion on state machines
« Reply #35 on: May 17, 2018, 03:38:04 pm »
You ALWAYS have to trap the possibility of an invalid state

Why? Unless you calculate your states, which is relatively rare, you assign the values directly or draw them from some sort of table. In either case, the probability of getting an invalid state is slim to none.

It is more than likely that somebody will code "state++;" to move onto the next state. Works fine until somebody else removes a state from the middle of a chain of states. Also, table driven state machines are quite common, at least in "programming 201" implementations.

One nice feature of using a state machines you can put the state variable into a buffer, so when debugging or looking at crash dumps you can see what states preceded the current one. Very handy.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 2114
  • Country: it
Re: Discussion on state machines
« Reply #36 on: May 17, 2018, 04:27:13 pm »
There are many that go from FSM diagram or FSM text to executable C.

Going the other way would require that the C has been written in a sane manner (starting with no macros!) and probably using a specific set of design patterns. If you are expecting something to work well with arbitrary C (e.g. nested case statements!), then you are expecting to have solved several seriously intractable problems :)

the idea is that provided i can trust this C->Graph converter, because it needs me to write code in a certain (hopefully better) manner, i can then look at the graph and be confident i didn't make stupid mistakes. then with the graph it's easier to read and analyze.

I drew the graph of my previously mentioned task, after the frankensteining.. it's a bit of a mess, while being still logical

I like the states table idea.
I like the array of states trace idea, for debugging.
« Last Edit: May 17, 2018, 04:34:02 pm by JPortici »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 6991
  • Country: gb
    • Having fun doing more, with less
Re: Discussion on state machines
« Reply #37 on: May 17, 2018, 05:58:47 pm »
As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.

Regarding that article I agree with the first comment "This is an excellent troll and strawman argument.".

For those who don't want to take the time to read it, here is a summary:

Old computers supported C.
Modern computers all support C.
Modern computers are complex.
Modern computers have issues.

Therefore continued support for C is the cause of everything that is wrong with computers today (incl Specter & Meltdown).

(Author must be one of those functional programming types)

OK, here's an example of the problem, from that article (read the article for the details)...
"According to the results of the survey, 36 percent were sure that they would be, and 29 percent didn't know. Depending on the compiler (and optimization level), it may or may not be. This is a fairly trivial example, yet a significant proportion of programmers either believe the wrong thing or are not sure."

That's an indication that C is part of the problem; I prefer tools that are part of the solution.

Regrettably C/C++ is littered with such things. I remember the triumphant announcement of the first C/C++ compiler that fully implemented the standard - 6 years after the standard was published. That was in the mid-noughties, so presumably it was the '99 standards.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 6991
  • Country: gb
    • Having fun doing more, with less
Re: Discussion on state machines
« Reply #38 on: May 17, 2018, 06:08:41 pm »
I prefer switch/case for state machines.    The compiler will generally implement with jump table.     You ALWAYS have to trap the possibility of an invalid state so I generally find it cleaner than a function pointer table.     The minute you need logic for an invalid value for your state value, you might as well use a case structure.  There might be an esoteric method in C to trap invalid function pointers but I generally avoid the super elegant solutions.

You'll have to explain that in words of one syllable.

Since you have to initialise every element of the array (statically at compile time if you have any sense) then you simply "fill in" every state/event with a valid function pointer. Many such pointers are likely to be to "panicAndHalt()" or "defaultIgnore()".

If you are worried about an index being out of bounds, then use your compiler to do the error checking and/or only allow the next state to be chaned in a function that checks array bounds. If that isn't sufficient then you shouldn't be using a language which can cast a car into a sandwich.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: Fire Doger

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 6991
  • Country: gb
    • Having fun doing more, with less
Re: Discussion on state machines
« Reply #39 on: May 17, 2018, 06:12:24 pm »
You ALWAYS have to trap the possibility of an invalid state

Why? Unless you calculate your states, which is relatively rare, you assign the values directly or draw them from some sort of table. In either case, the probability of getting an invalid state is slim to none.

It is more than likely that somebody will code "state++;" to move onto the next state. Works fine until somebody else removes a state from the middle of a chain of states. Also, table driven state machines are quite common, at least in "programming 201" implementations.

If that is a problem that you can't overcome, then firstly you shouldn't be using C/C++ for that project, and secondly you have bigger problems (even if you don't realise it yet).

Quote
One nice feature of using a state machines you can put the state variable into a buffer, so when debugging or looking at crash dumps you can see what states preceded the current one. Very handy.

Yes, that is very valuable in design, comissioning, operation, and maintenance. Adding events into the buffer can also be a help.
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1535
  • Country: nz
Re: Discussion on state machines
« Reply #40 on: May 17, 2018, 07:22:07 pm »
OK, here's an example of the problem, from that article (read the article for the details)...
"According to the results of the survey, 36 percent were sure that they would be, and 29 percent didn't know. Depending on the compiler (and optimization level), it may or may not be. This is a fairly trivial example, yet a significant proportion of programmers either believe the wrong thing or are not sure."

That's an indication that C is part of the problem; I prefer tools that are part of the solution.
No, it was trick question.

Quote
The question impiled by the article
You have a structure that is allowed (by the standard) to be padded to a convenient size for the compiler. You create an instance of that structure. You zero the structure. You then set some of the elements of the structure to non-zero values. Is the value of the padding now guaranteed to be zero?   Yes / No / Don't know

No matter which answer you pick, you are wrong. Pick one and I'll prove the opposite to you (with code).

It is unfair as me asking you "Could you write a program in (your preferred language) to calculate how many fairies can dance on the head of a pin?".
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 6991
  • Country: gb
    • Having fun doing more, with less
Re: Discussion on state machines
« Reply #41 on: May 17, 2018, 07:47:11 pm »
OK, here's an example of the problem, from that article (read the article for the details)...
"According to the results of the survey, 36 percent were sure that they would be, and 29 percent didn't know. Depending on the compiler (and optimization level), it may or may not be. This is a fairly trivial example, yet a significant proportion of programmers either believe the wrong thing or are not sure."

That's an indication that C is part of the problem; I prefer tools that are part of the solution.
No, it was trick question.

Quote
The question impiled by the article
You have a structure that is allowed (by the standard) to be padded to a convenient size for the compiler. You create an instance of that structure. You zero the structure. You then set some of the elements of the structure to non-zero values. Is the value of the padding now guaranteed to be zero?   Yes / No / Don't know

No matter which answer you pick, you are wrong. Pick one and I'll prove the opposite to you (with code).

That's very revealing because, if you think about it, what you claim to be able to do is simply impossible.

Hint: you might be able to make your point for one compiler with one target machine with one set of compiler flags - for one version of that compiler (because C compilers/linkers can and do change the code they emit).
« Last Edit: May 17, 2018, 07:51:17 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1535
  • Country: nz
Re: Discussion on state machines
« Reply #42 on: May 17, 2018, 08:13:45 pm »
OK, here's an example of the problem, from that article (read the article for the details)...
"According to the results of the survey, 36 percent were sure that they would be, and 29 percent didn't know. Depending on the compiler (and optimization level), it may or may not be. This is a fairly trivial example, yet a significant proportion of programmers either believe the wrong thing or are not sure."

That's an indication that C is part of the problem; I prefer tools that are part of the solution.
No, it was trick question.

Quote
The question impiled by the article
You have a structure that is allowed (by the standard) to be padded to a convenient size for the compiler. You create an instance of that structure. You zero the structure. You then set some of the elements of the structure to non-zero values. Is the value of the padding now guaranteed to be zero?   Yes / No / Don't know

No matter which answer you pick, you are wrong. Pick one and I'll prove the opposite to you (with code).

That's very revealing because, if you think about it, what you claim to be able to do is simply impossible.

Hint: you might be able to make your point for one compiler with one target machine with one set of compiler flags - for one version of that compiler (because C compilers/linkers can and do change the code they emit).
I'll bite....

This will ALWAYS have zeros in the padding (The 'Yes' example):
Code: [Select]
int main(int argc, char *argv[])
{
  struct padded s;
  int i;

  printf("'s' is %i bytes of memory\n", (int)sizeof(s));
  /* Clear structure*/
  memset(&s,0,sizeof(s));
  /* Set  some values */
  s.a = 0xAA;
  s.b = 0xBBBBBBBB;

  printf("Byte dump:\n");
  for(i = 0; i <sizeof(s); i++) {
    printf("%02x ",((unsigned char *)&s)[i]);
  }
  printf("\n");

  return 0;
}

Is very likely to have random junk in the padding, as it depends on things we have no knowledge of  (The "Don't know" example)

Code: [Select]
#include <stdio.h>
#include <memory.h>

struct padded {
  unsigned char a;
  unsigned int  b;
};

int main(int argc, char *argv[])
{
  struct padded s;
  int i;

  printf("'s' is %i bytes of memory\n", (int)sizeof(s));
  /* Clear structure*/
  s.a = 0;
  s.b = 0;

  /* Set  some values */
  s.a = 0xAA;
  s.b = 0xBBBBBBBB;

  printf("Byte dump:\n");
  for(i = 0; i <sizeof(s); i++) {
    printf("%02x ",((unsigned char *)&s)[i]);
  }
  printf("\n");

  return 0;
}

And finally this proves that even when you zero out every fields in a structure the padding are not guaranteed to be zero (The "No" example):

Code: [Select]
#include <stdio.h>
#include <memory.h>

struct padded {
  unsigned char a;
  unsigned int  b;
};

int main(int argc, char *argv[])
{
  struct padded s;
  int i;

  memset(&s,0xFF,sizeof(s));
  printf("'s' is %i bytes of memory\n", (int)sizeof(s));

  /* Clear every field in the structure*/
  s.a = 0;
  s.b = 0;

  /* Set  some values */
  s.a = 0xAA;
  s.b = 0xBBBBBBBB;

  printf("Byte dump:\n");
  for(i = 0; i <sizeof(s); i++) {
    printf("%02x ",((unsigned char *)&s)[i]);
  }
  printf("\n");

  return 0;
}

I now challenge you to find a compiler and a set of options that breaks *any* of these examples.

Of course on some architectures and/or switches padding will not be needed. I assume that with no padding present the question is invalid - you can't say anything about the value of padding when the padding doesn't exist.
 

Offline SparkyFX

  • Regular Contributor
  • *
  • Posts: 118
  • Country: de
Re: Discussion on state machines
« Reply #43 on: May 17, 2018, 08:53:12 pm »
I tend to implement very small, 2D state machines just by a step counter.

It seems that I may have been misinterpreting the "pointer to a function is a no-go" for years. I understand this that as long as the function pointer is const type, the world is safe.
Every function call at link time is already equivalent to a constant function pointer - for statically linked libraries. Does that imply dynamically linked libraries are forbidden?

Quote
The question impiled by the article
You have a structure that is allowed (by the standard) to be padded to a convenient size for the compiler. You create an instance of that structure. You zero the structure. You then set some of the elements of the structure to non-zero values. Is the value of the padding now guaranteed to be zero?   Yes / No / Don't know

No matter which answer you pick, you are wrong. Pick one and I'll prove the opposite to you (with code).
How is the padding (gaps between fields) of a structure changed by changing values inside the structure at runtime? Why should the padding length therefore become zero?
Accessing raw memory and disabling compiler checks might allow to write to the pad bytes (if the compiler included them at all) which are to be allocated by the memory management, but that would also not change the length of the padding, only it´s content.

Working in electronics is like a good puzzle.
Comes with: More Parts! Complications™! Physics! English! Pulled out Hairs! Batteries included!
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1535
  • Country: nz
Re: Discussion on state machines
« Reply #44 on: May 17, 2018, 09:20:32 pm »
Quote
The question impiled by the article
You have a structure that is allowed (by the standard) to be padded to a convenient size for the compiler. You create an instance of that structure. You zero the structure. You then set some of the elements of the structure to non-zero values. Is the value of the padding now guaranteed to be zero?   Yes / No / Don't know

No matter which answer you pick, you are wrong. Pick one and I'll prove the opposite to you (with code).
How is the padding (gaps between fields) of a structure changed by changing values inside the structure at runtime? Why should the padding length therefore become zero?
Accessing raw memory and disabling compiler checks might allow to write to the pad bytes (if the compiler included them at all) which are to be allocated by the memory management, but that would also not change the length of the padding, only it´s content.
Sorry for the confusion - not the quantity of padding (which is fixed at compile time, and depends on architecture, #pragmas, compiler options and so on), but the values held in that padding (e.g. the bytes that would be written to a file if you wrote the structure to a file with "fwrite()").
 

Offline SparkyFX

  • Regular Contributor
  • *
  • Posts: 118
  • Country: de
Re: Discussion on state machines
« Reply #45 on: May 17, 2018, 09:29:02 pm »
Yeah, thanks, i stumbled over "Is the value of the padding now guaranteed to be zero?" ... it means the content of pad bytes, not their length.
However, no one guaranteed their existence, cause... it depends on the alignment of the structure.

Working in electronics is like a good puzzle.
Comes with: More Parts! Complications™! Physics! English! Pulled out Hairs! Batteries included!
 

Offline gmb42

  • Regular Contributor
  • *
  • Posts: 157
  • Country: gb
Re: Discussion on state machines
« Reply #46 on: May 17, 2018, 09:43:02 pm »
There's a whole embedded OS and graphical IDE for state machines over here: http://www.state-machine.com/
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 1358
  • Country: us
Re: Discussion on state machines
« Reply #47 on: May 17, 2018, 11:01:30 pm »
An excellent point and one of the many reasons I prefer C for most things.  It's easy to understand the rules and what will actually happen.

Er, no. Or at least only at a superficial level.

As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.

Quote

Of course, for numerical work FORTRAN is better.  Lex, yacc, awk and MATLAB/Octave all have their places too.

Er, yes :)

Sadly, I would not disagree about the knowledge level of the generic programmer.  My general observation is that the entire compile, link, execute cycle is magic to most for any language, even K&R C or C89.

I'm not the generic programmer.  I have copies of the language standards and refer to them whenever needed.  I *never* call a library function without checking the argument types and orders unless it's a function I just used a few minutes earlier. I also have and have read several books on compiler optimization and "Computer Architecture:  A Quantitative Approach" by Patterson and Hennessy.  I've only read the first 3 eds. of the latter as I've not had a serious project since the 4th ed came out.  But it would be the first thing on my To Do list if I were tasked with a high performance programming  assignment.

Programmers have even less of a clue what C++ does.  In fact, I assert that no one understands C++.  However, I shall not bother with my canonical example.  Suffice it to say that I can present a trivial code example which will require reading all the source code, the language standard *and* the compiler implementation notes to figure out what one line does. 

I read language and processor manuals for entertainment for many years. I am what Fred Brooks described as a "language lawyer". 

For example, section 8.3.5  of the F77 standard says "upon return from a function or subroutine, named COMMON may be undefined".  This language was inserted into the standard at the behest of Burroughs so that they could state that the new Burroughs 5000 had an F77 compliant compiler.  That machine was one of the first stack based machines and so far as I know the only machine that implemented a tagged architecture. Every memory location had bits that stored the type of value stored at that address.

When the first RISC machines came out, I spent a lot of time explaining to people what they needed to do to make their code work.  I've also done little stunts such as demonstrate passing data between functions without using globals or arguments by exploiting the order in  which automatic variables appeared in the stack frame.

Curiously, I've never seriously used F95 and later.  Copies of the standard are expensive and I've never found a decent book on modern FORTRAN that explained what the underlying memory map and structure was.  Of course, that is in part because I can seamlessly move between C89/99 and F77.  I got a 6x speedup in a program by having C create a table of F77 function pointers and addresses on the first call and then executing the table after the first call.  This was a big deal with users who were processing 100 million line ASCII files.
 

Offline NorthGuy

  • Frequent Contributor
  • **
  • Posts: 860
  • Country: ca
Re: Discussion on state machines
« Reply #48 on: May 17, 2018, 11:36:58 pm »
It is more than likely that somebody will code "state++;" to move onto the next state.

Cannot do "state++" if state is a function pointer.
 

Offline SiliconWizard

  • Frequent Contributor
  • **
  • Posts: 557
  • Country: fr
Re: Discussion on state machines
« Reply #49 on: May 17, 2018, 11:37:43 pm »
As merely one set of examples of how developers have been demonstrated to be confused, have a look at https://queue.acm.org/detail.cfm?id=3212479 and its references.

Regarding that article I agree with the first comment "This is an excellent troll and strawman argument.".
(...)

Pretty much so. This article has been posted to the comp.lang.c newsgroup and has elicited a fair amount of posts.

Attention whores (whether this is done on purpose or not) live on this kind of negative-sided, fallacious articles, that unfortunately tend to generate a lot more traction than constructive ones.
 
The following users thanked this post: Frank, SparkyFX


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf