How would the dispatch table get corrupted? If the dispatch table is compiled down into an executable in exactly the same manner an if/else would be, then I can't think of a reasonable corruption vector that would corrupt a compiled-in dispatch table, but not a similarly compiled-in if/else block of code.
As for an off-by-one, that /never/ happens in an if-else block either, and as long as you do bounds checking, you might call the wrong function, but that's not a 'random pointer address'.
You have a very good point that this technique doesn't actually lessen program complexity. It does, however, help the fragmented business logic into tables that are more easily dealt with when the business end changes.
The 'error of some kind' is just as much an error as a missing 'else' in a long if/else if/else if block or a 'default' section in a switch.
> How would the dispatch table get corrupted? If the dispatch table is compiled down into an executable in exactly the same manner an if/else would be, then I can't think of a reasonable corruption vector that would corrupt a compiled-in dispatch table, but not a similarly compiled-in if/else block of code.
Without doing any actual experiments and assuming native code, the dispatch table is liable to go into the .data section of the binary with the rest of the globals/statics, which should be read/write (if you're lucky, you made it const and it's in .rdata which is read-only). An unmitigated buffer overflow in a different item in .data is liable to corrupt the table. Typically, the .text section (the program code) is not writable.
How would the dispatch table get corrupted? If the dispatch table is compiled down into an executable in exactly the same manner an if/else would be, then I can't think of a reasonable corruption vector that would corrupt a compiled-in dispatch table, but not a similarly compiled-in if/else block of code.
As for an off-by-one, that /never/ happens in an if-else block either, and as long as you do bounds checking, you might call the wrong function, but that's not a 'random pointer address'.
You have a very good point that this technique doesn't actually lessen program complexity. It does, however, help the fragmented business logic into tables that are more easily dealt with when the business end changes.
The 'error of some kind' is just as much an error as a missing 'else' in a long if/else if/else if block or a 'default' section in a switch.