-
Only MISRA may give their reasons.
But in general function pointer arrays in comparison with switch have close to no benefits. Due to limitations of C syntax, the code may be a bit more concise. But that’s it.
In terms of performance both are compiled to very similar machine code.switch version has no branching, though nowadays branching in most circumstances is not inflicting heavy penalty.(1) Function pointers array is opaque to optimizers, but potential optimizations are scarce even for the switch option. Depending on specific architecture either may increase footprint, but by a negligible amount. So here neither of the solutions has consistent advantage.
The disadvantages of function pointers arrays are, however, notable. From security perspective it must involve a machine instruction, which takes an arbitrary variable value as its parameter. This is an open invitation to RCE, ACE, DoS, and other attacks based on gaining control over program flow. Putting jumps arrays in ROM is of no use, because at machine code level the data from ROM is loaded into RAM or registers, or at least is selected using data in RAM or registers. In comparison switch has no such dependency. From safety perspective, the code is much harder to analyze or prove its validity.(2) Static analysis becomes mostly useless, code coverage testing can detect neither all cases, nor dead code.
This of course applies to static code and C. If the situation really calls for a dynamic approach, there is little choice. And the advice is not as strong for similar constructs in other languages, where layers of type safety, abstraction and JIT-ing designed to deal with this kind of dispatch make the risk much lower. Of course safety issues may still remain.
Somebody mentioned that an interrupt vector table is just that. This is comparing apples to oranges. It’s like saying, that goto has no issues, because — after all — at machine level all code is just a bunch of jumps. No, machine level code and human-written code are two different scenarios, with separate set of factors affecting their evaluation. It’s also not as universal. AVR, for example, uses an equivalent of optimized switch.
(1) And a function call is usually much more expensive than branching.
(2) It may seem otherwise, if you look at your own code and a trivial situation. To see, what I am referring to, try reverse-engineering (or even understanding source) code of somebody else, where indirect invocation is involved in a project of hundred source files.
-
By constant I (and the designers of MISRA) mean a variable sits in read-only memory. Not RAM. Typically everything you declare const in C on a microcontroller ends up in flash which is read-only.
That's true for small embedded controllers, which were the main targets when MISRA started. However, I don't think they distinguish between that situation, and the bigger systems in modern cars where many processors boot from some form of flash into RAM. You may have protection where the relevant segment is declared read only in the MMU, but its not the solid situation you have in a small MCU where anything constant is truly constant, unless the developer screwed up where they allocate stuff really badly.
From my experience the biggest cause of memory corruption are buffer overruns. So allowing function pointers in read-only memory only, is a sensible compromise IMHO. At least you won't get the situation that code is executed from a random address.
-
Arrays of function pointers may have close to no benefit over switch statement.
But lists of function pointers are a whole another story
And they make static analysis even more hopeless. -
Arrays of function pointers may have close to no benefit over switch statement.
Some compilers turn switch statements into a bunch of function calls, when the "case" values are in a contiguous block.
But lists of function pointers are a whole another story
And they make static analysis even more hopeless. -
Arrays of function pointers may have close to no benefit over switch statement.
Yes. Actually, they are likely to be worse in terms of performance in many cases, and make code potentially more fragile. 'switch' in C yields surprisingly well optimized compiled code with most modern compilers.
People use this approach usually because it looks nicer, but it is harder (to impossible) to statically analyze, and is potentially prone to run-time security issues (if at any point, one function pointer is in a writable memory area, which could get corrupted.) That is less of an issue if you only index a fixed array of function pointers located in a non-writable area (like flash), although you still need to make sure that the index never gets out of bounds, or else the result is not pretty.
Function pointers have many uses though outside of this, more justified, to make code more generic. If the zero-defect bar is not a goal, obviously it's just a matter of benefit/risk ratio, but as long as it is (which you'd hope it is for safety-critical stuff), the idea is to avoid risks altogether when possible, which is the whole idea behind these coding guidelines. They often look overkill to a degree that may appear stupid, but the goal is to avoid running into any risk that can be avoided, even if that means writing pretty "annoying" code.
-
To see, what I am referring to, try reverse-engineering (or even understanding source) code of somebody else, where indirect invocation is involved in a project of hundred source files.
This. I was given some quite complex code as an example of achieving some end, and it was really very painful trying to work out what it did, or when, or why. -
To see, what I am referring to, try reverse-engineering (or even understanding source) code of somebody else, where indirect invocation is involved in a project of hundred source files.
This. I was given some quite complex code as an example of achieving some end, and it was really very painful trying to work out what it did, or when, or why.
And the other
I have seen a commercial product which was essentially a glorified telecoms FSM. As is traditional, it was written in a scrotty little scripting language designed to allow late customer-specific tweaks to the product.
Over the years the FSM had grown so that the if-then-else clauses were in some cases nested 10 deep. Apparently simple changes took months. No, I had nothing to do with that product!
Now, what was that about switches being easy to understand/change?
-
A switch doesn't need nested ifs, does it? You could have a switch (event) for each case (state), but the only real hassle in either case (sorry) is that it could be a long primary switch. Still, that doesn't make any difference to the code really, and it's easy to understand: just run down until you get to the state, run through that until you hit the event, there's the function that deals with it (or one or two like statement if it's short'n'sweet). With no effort, you can tell what event is valid in which state(s) to call whatever function(s). And just as easily find what event(s) in which state(s) could call the function you're looking at.
Edit: too obvious to mention, but... you can put comments in there too, in case you need to say why whatever is happening there. -
A switch is merely syntactic sugar for multiple if statements; they are equivalent.s
What could have been done is irrelevant; what was done is a useful counterexample to the concept that FSMs and switches are easy/simple to understand.
Quite frankly that project was an example of extreme base taste in several dimensions, perpetrated deliberately over many years, with there being business justification for each change. From the point of view of this discussion, so what
It is one example where comments definitely couldn't have helped. And I'm a fan of good comments, and hate the agile/XP religion that claims comments are of negative value! -
A switch is merely syntactic sugar for multiple if statements; they are equivalent.s
Yes, but one brings clarity on the page, and the other is much harder to read. If the cases are complex you have no choice but to use a bunch of if-then-elses, although they can be laid out on the page in an unnested manner, to illuminate their switch like quality,
-
tggzzz: if these were nested conditionals, how would you express it in a more readable way in a lookup array? I am aware of perfect hashing approaches, but clarity is the last term I would use to describe them.
… or were you responding to my post… skipping the conditions?
-
A switch is merely syntactic sugar for multiple if statements; they are equivalent.s
Yes, but one brings clarity on the page, and the other is much harder to read. If the cases are complex you have no choice but to use a bunch of if-then-elses, although they can be laid out on the page in an unnested manner, to illuminate their switch like quality,
Not just that, but by construction, it's testing a single object against a number of different values, while a sequence of if's can do absolutely anything *and* is by nature a recipe for duplicated code (if just for testing the object). Which absolutely sucks in terms of maintainability.
Nested testing or whatever has absolutely nothing to do with it. It's a completely orthogonal problem. You can call a function to handle each case of the switch, the switch itself can be as clean as that.
The difference with an array of function pointers is that it's statically analyzable and avoids some of the pitfalls we mentioned for function pointers. Another bonus point for the switch is that each case can call a function with possibly different parameters, while with an array of function pointers, they all have to have the same signature. And so you then often resort either to using void * pointers (so no type checking), or passing around convoluted structures with a lot of context in them that most of your functions won't care about (so another source of potential problem, lack of separation of concerns.)
So again, function pointers certainly have good use cases, but not for replacing a switch construct in general, IMO.
-
tggzzz: if these were nested conditionals, how would you express it in a more readable way in a lookup array? I am aware of perfect hashing approaches, but clarity is the last term I would use to describe them.
… or were you responding to my post… skipping the conditions?
Neither.
I was responding to the posts I quoted, or in a few cases to the immediately preceding post.
Do you have sufficient brainpower to remember all the points made by each contributor in all the 85 posts in this thread? I don't.
For a more specific response, please provide the context to your questions. -
Typically everything you declare const in C on a microcontroller ends up in flash which is read-only.
That's true for small embedded controllers
Not even there - for example on AVR, every const, even including string literals, will be in RAM because ROM access is weird. For other systems, it's really fifty-sixty situation; maybe nctnico's assumption holds, maybe not. The developer should know, though. Better use exact language here, and if read-only memory is meant, then say so, not "const". -
Typically everything you declare const in C on a microcontroller ends up in flash which is read-only.
That's true for small embedded controllers
Not even there - for example on AVR, every const, even including string literals, will be in RAM because ROM access is weird. For other systems, it's really fifty-sixty situation; maybe nctnico's assumption holds, maybe not. The developer should know, though. Better use exact language here, and if read-only memory is meant, then say so, not "const".
Yep. Especially since where things end up in memory ultimately depends on the linker (thus on the linker script for those linkers that are scriptable, which covers all targets supported by at least GCC and LLVM, and many other compilers too).
It takes a 30 s linker script modification to make all const data, even if the compiler has decided to put it in the typical ".rodata" section, go directly to RAM. Otherwise, yes, some targets with odd architectures are not even flexible enough for that and data may end up in various memory areas for specific reasons.
I've written a small executive for a MCU just a few days ago that puts absolutely everything in RAM, as everything has to execute, read and write in it, so yes, all const data lies in RAM too.
-
Typically everything you declare const in C on a microcontroller ends up in flash which is read-only.
That's true for small embedded controllers
Not even there - for example on AVR, every const, even including string literals, will be in RAM because ROM access is weird. For other systems, it's really fifty-sixty situation; maybe nctnico's assumption holds, maybe not. The developer should know, though. Better use exact language here, and if read-only memory is meant, then say so, not "const".
Yep. Especially since where things end up in memory ultimately depends on the linker (thus on the linker script for those linkers that are scriptable, which covers all targets supported by at least GCC and LLVM, and many other compilers too).
It takes a 30 s linker script modification to make all const data, even if the compiler has decided to put it in the typical ".rodata" section, go directly to RAM. Otherwise, yes, some targets with odd architectures are not even flexible enough for that and data may end up in various memory areas for specific reasons.
I've written a small executive for a MCU just a few days ago that puts absolutely everything in RAM, as everything has to execute, read and write in it, so yes, all const data lies in RAM too.
Yep. Yet another example of someone thinking they know what the C keywords mean.
C has grown so baroquely complex that very few people understand it as well as they think they do - and the people that do know realise how little they know and where the skeletons are buried.
C has mutated from its original concept so much that it has become part of the problem (i.e. not the solution).
In the early 90s the C++ committee spent years discussion whether it should be possible or impossible to "cast away const" (needed for debuggers and optimisations, respectively). I believe the decided it should be possible. Does C allow it now? Has that changed over the decades? -
tggzzz: if a person is commenting on a direct response to my post, I find it reasonable to suspect they did read my post. Perhaps I am old-fashioned and not fitting the modern world.
-
I guess this is the context...
tggzzz: if these were nested conditionals, how would you express it in a more readable way in a lookup array? I am aware of perfect hashing approaches, but clarity is the last term I would use to describe them.
… or were you responding to my post… skipping the conditions?
Neither.
I was responding to the posts I quoted, or in a few cases to the immediately preceding post.
Do you have sufficient brainpower to remember all the points made by each contributor in all the 85 posts in this thread? I don't.
For a more specific response, please provide the context to your questions.
... to which you wrote...tggzzz: if a person is commenting on a direct response to my post, I find it reasonable to suspect they did read my post. Perhaps I am old-fashioned and not fitting the modern world.
Is it now fashionable to presume that you are the centre of the conversation, and that everybody automatically remembers what you wrote?
Is it no longer fashionable to help the reader understand your point by including the context? In general I have no idea of which of yesterday's (or last week's) posts you are referring to, and am not going to waste my time guessing!
Note that quoting the context is easy: just click the "Quote" button above the post in question.
This forum encourages long subtle conversations by including multiple levels of the context, so it is easy to keep track of multiple sub-threads. Other forums (e.g. stackexchange, edaboard) don't allow multi-level quoting, thereby limiting conversations to boring "which button do I press to turn the splutget's flangle blue?".
Contrariwise this forum enables interesting and subtle on-going conversations, by allowing multi-level quotes in a single thread. That's the nearest currently available to the hierarchical email/usenet readers that were developed to enable people to share opinions and ideas in a distributed world. -
In the early 90s the C++ committee spent years discussion whether it should be possible or impossible to "cast away const" (needed for debuggers and optimisations, respectively). I believe the decided it should be possible. Does C allow it now? Has that changed over the decades?
I think that is a natural consequence of evolution. If you ban const being cast away an ENORMOUS amount of great existing code becomes unusable by well written new code. If you allow const to be cast away new code is less robust than it might otherwise be. They probably should have made this a compiler option. Then you can ban it for entirely new clean code, and allow it when you need to interwork. That should have been an easy choice for a committee to agree upon, but too many zealots are usually involved.
-
In the early 90s the C++ committee spent years discussion whether it should be possible or impossible to "cast away const" (needed for debuggers and optimisations, respectively). I believe the decided it should be possible. Does C allow it now? Has that changed over the decades?
I think that is a natural consequence of evolution. If you ban const being cast away an ENORMOUS amount of great existing code becomes unusable by well written new code. If you allow const to be cast away new code is less robust than it might otherwise be. They probably should have made this a compiler option. Then you can ban it for entirely new clean code, and allow it when you need to interwork. That should have been an easy choice for a committee to agree upon, but too many zealots are usually involved.
Not an easy choice, because there are competing important valid forces in each direction.
There was far less existing code in the early 90s, when C (and C++) had to decide whether to be a general purpose programming language or a low level systems language. Either choice would have been valid. In trying to satisfy both, they satisfied neither.
Engineers and the marketplace have chosen that C (and C++) are not the future of general purpose programming languages: too complex to understand and use, too many gotchas, too low level. That leaves close to the silicon and systems uses, and the compromises made for general purpose use have complicated using C there. Hence the rise of Rust, and to a lesser extent, Go.
C will, of course continue, in the same way that COBOL continues. The faster C++ withers, the better. -
How is making it user selectable a difficult decision? It allows any view point to be catered for.In the early 90s the C++ committee spent years discussion whether it should be possible or impossible to "cast away const" (needed for debuggers and optimisations, respectively). I believe the decided it should be possible. Does C allow it now? Has that changed over the decades?
I think that is a natural consequence of evolution. If you ban const being cast away an ENORMOUS amount of great existing code becomes unusable by well written new code. If you allow const to be cast away new code is less robust than it might otherwise be. They probably should have made this a compiler option. Then you can ban it for entirely new clean code, and allow it when you need to interwork. That should have been an easy choice for a committee to agree upon, but too many zealots are usually involved.
Not an easy choice, because there are competing important valid forces in each direction.
There was far less existing code in the early 90s, when C (and C++) had to decide whether to be a general purpose programming language or a low level systems language. Either choice would have been valid. In trying to satisfy both, they satisfied neither.
Engineers and the marketplace have chosen that C (and C++) are not the future of general purpose programming languages: too complex to understand and use, too many gotchas, too low level. That leaves close to the silicon and systems uses, and the compromises made for general purpose use have complicated using C there. Hence the rise of Rust, and to a lesser extent, Go.
C will, of course continue, in the same way that COBOL continues. The faster C++ withers, the better.
The marketplace can't decide what it wants for the future. The last new language to get and hold a strong position was C/C++. Everything else comes and goes, as people realise the latest new thing is no panacea. Python seems to be doing pretty well at the moment, but just a few years ago Java was going quite well, had masses of cash behind it, and has fallen into decline.
-
How is making it user selectable a difficult decision? It allows any view point to be catered for.In the early 90s the C++ committee spent years discussion whether it should be possible or impossible to "cast away const" (needed for debuggers and optimisations, respectively). I believe the decided it should be possible. Does C allow it now? Has that changed over the decades?
I think that is a natural consequence of evolution. If you ban const being cast away an ENORMOUS amount of great existing code becomes unusable by well written new code. If you allow const to be cast away new code is less robust than it might otherwise be. They probably should have made this a compiler option. Then you can ban it for entirely new clean code, and allow it when you need to interwork. That should have been an easy choice for a committee to agree upon, but too many zealots are usually involved.
Not an easy choice, because there are competing important valid forces in each direction.
There was far less existing code in the early 90s, when C (and C++) had to decide whether to be a general purpose programming language or a low level systems language. Either choice would have been valid. In trying to satisfy both, they satisfied neither.
Engineers and the marketplace have chosen that C (and C++) are not the future of general purpose programming languages: too complex to understand and use, too many gotchas, too low level. That leaves close to the silicon and systems uses, and the compromises made for general purpose use have complicated using C there. Hence the rise of Rust, and to a lesser extent, Go.
C will, of course continue, in the same way that COBOL continues. The faster C++ withers, the better.
The marketplace can't decide what it wants for the future. The last new language to get and hold a strong position was C/C++. Everything else comes and goes, as people realise the latest new thing is no panacea. Python seems to be doing pretty well at the moment, but just a few years ago Java was going quite well, had masses of cash behind it, and has fallen into decline.
Library "maker" chooses one and expects library "user" to take account of that in their code. User doesn't. Variant: the inverse, or someone uses a different library that uses another library. All people in different companies, of course.
That is all too brittle, and likely to subtly fail. Good luck trying to write unit/regression tests to validate multiprocessor guarantees!
I see no evidence that Java is declining. Sure the fervour is dissipating, which is inevitable when something becomes the mainstream. -
I see no evidence that Java is declining. Sure the fervour is dissipating, which is inevitable when something becomes the mainstream.
Its hard to say. Java has been driven out of a lot of publicly facing places where its clear what is being used. However, if its still strong in business applications it may have locked itself in, the way COBOL did in my youth, and we wouldn't be all that aware.
-
I see no evidence that Java is declining. Sure the fervour is dissipating, which is inevitable when something becomes the mainstream.
Its hard to say. Java has been driven out of a lot of publicly facing places where its clear what is being used. However, if its still strong in business applications it may have locked itself in, the way COBOL did in my youth, and we wouldn't be all that aware.
It is strong in enterprise applications, and shows no sign of being superseded. That includes technical areas such as soft realtime telecom and fintech, as well as the obvious database backed web services.
The biggest negative is that Oracle bought Sun, but there are open variants if you don't like your gonads being squeezed. -
I don't quite agree with a couple of your points here, but for a common root reason:
Yep. Yet another example of someone thinking they know what the C keywords mean.
'const' just means that the developer is not allowed to modify the value explicitely in their code. It means nothing else, and indeed assuming anything else is either from a misconception, or from relying on implementation-defined behaviors (which is common when using C). So whether it comes from a misconception or a conscious decision depends a lot on the developer and context. You can just probably assume it's more the former when the person doesn't seem to be able to make that distinction.C has grown so baroquely complex that very few people understand it as well as they think they do
That's mainly what I don't agree with. C is still very simple. Try to compare its complexity to any modern language. It still has some "quirks" certainly, most, if not all, of them coming from the origins and not ones that have been added along the way. One frequent complaint is about optimizations (which is entirely implementation-defined), but that comes from the misconception that C would be this language that is translated *exactly* as you would write it, which is not what any programmming language does. Heck, even assembly may not be executed in order...
As I routinely say, the main issue with C is not at all that's it's complex, it's the fact that if people don't understand it, it's because they have never learned it. Not because it's complex.
(If anyone thinks C is too complex to learn, please just never touch C++, Ada, Rust, and many others.)
It's a major issue. Many (most?) people using C just assume they can spit out code without ever having learned the language, apart from having followed basic tutorials (yes, even in academia these days) and copied stuff around until that has seemed to sink in. It's almost a miracle that C is still being used successfully in many areas these days, but also makes you understand a bit better why guidelines such as MISRA are unavoidable in some fields, even if that can be considered unfortunate.
The interesting part is that some languages are so inherently more complex than C, that people have literally no choice other than learning them properly before being able to do much of anything with them, which in turn leads to a better command of the language. In other words, that's precisely because C appears so simple that many developers have never bothered to actually *learn* it. The other side, to be fair, being that since C allows you to deal with very low-level stuff, you get the complexity, not of the language itself, but of dealing with low-level stuff. And so people keep asking questions about C when the questions are really about the low-level aspects, that, sure, C doesn't abstract a whole lot (but it's the whole point.)