The best you can come up with is how tangled the code in a hand-written lexer looks? I may have skimmed a bit towards the end, but, did you actually find a bug?
That code is really bad. Dunno about you, but to me this handcrafted entanglement looks like the crap that any professional programmer should be ashamed of:
if ( .. )
{
for ( .. )
{
label:
...
}
}
else
{
if ( .. )
{
..
}
else
goto label;
..
}
The actual code is even worse than this as there's a second goto that jumps from the top for into one of else blocks at the bottom from where the control can go back to for via another goto ... I sort of can see how this code came about, but there is absolutely no excuse for checking in something this f*cked up.
If they wanted to show off, they should've just used the coroutines :-)
It has been explained that this is just a way of implementing a fast lexical scanner. This is the kind of code that you don't come up with, it is a mechanical implementation of a state machine.
Mechanical or not, this is a very untidy way of implementing a "fast lexical scanner". Even the Duff's device looks cleaner and more elegant in comparison. And it's not like there is a shortage of other implementation options that are as fast.
Didn't look like he pointed out any bugs - but that's not really the main point of a code review. It's all well and good for the compiler to understand the code and have it execute properly, but is it human-readable? Or maintainable? Having looked at the source file, I'd say that particular method is neither.
If they wanted to show off, they should've just used the coroutines :-)