deadalnix:
The presented example is insanely unsafe. By giving invalid
input, you can basically branch randomly.
The check added by the switch is what is required to make it
safe, so it isn't faster at the end.
The case in the article isn't very strong.
Thank you for your answer. We have not yet designed how D
computed gotos are, both in syntax and semantics. This means that
maybe there are ways to make them a little safer, in non-release
mode.
Part of the GCC-C code in the article was:
static void* dispatch_table[] = {
&&do_halt, &&do_inc, &&do_dec, &&do_mul2,
&&do_div2, &&do_add7, &&do_neg};
#define DISPATCH() goto *dispatch_table[code[pc++]]
In D there are no preprocessor macros and the array bounds are
enforced at run-time, this avoids some possible bugs of similar
code.
Also, instead of void* maybe a different type can be introduced,
so only label addresses of the current function can be put in
dispatch_table and pointer variables given to goto. This
statically avoids some other possible bugs.
It's true that in the end computed gotos are unsafe, you
generally need to validate the bytecode/state transition before
feeding them to the computed goto, and in D (unlike GCC-C) you
are able to forbid the usage of computed gotos in @safe
functions/methods. This doesn't avoid bugs, but helps contain
them in delimited places. We have the @safe/@trusted/@system for
a purpose.
In D modules like std.reflection suggested by Andrei are useful,
because D is usable to write lot of high-level code too, I use a
highly functional D style in some little D "scripts". But D is
also a system language, and sometimes I desire to use it for
tasks where C is used. GCC has computed gotos since many years
(and Clang supports them) and as you see in the linked article
some very common language interpreters you see around use
computed gotos if the C compiler supports them. This is not a
must-have feature for D, but dismissing it just because it's not
safe is a bad idea.
Bye,
bearophile
