raccのparser.rbとcparseの実装上の違いで、「振る舞いが異なる原因となるところを見つけました」と書きました.
その後、この予想を確かめるべくraccのリポジトリから、どの時点でcparseとparser.rbの処理が異なるようになったか、を
調べたのはhttp://i.loveruby.net/svn/public/racc/trunkです。
以前はcvsのリポジトリを使っていたようでしたが、現在はCVSのリポジトリにはアクセスで来ませんでした。
SVNのリポジトリでは、以下が最も古いログです。
r1611 | 1999-06-30 11:52:10 +0900 (水, 30 6月 1999) | 1 line
ただし、ディレクトリ構成も過去からずいぶん変更されているようで、あるリビジョン以前では、目的とするcparse.cの過去のリビジョンとのdiffをとるのが面倒になりました。
結局、raccの過去のアーカイブから調べたいバージョンを取ってきて、ローカルで展開して比較することにしました。
ログを元に推測が出来る分、当てずっぽうよりはずいぶんマシです.
さて私の予想で、今回も外れた部分があります。
私が注目していたのは、エラー回復モードに入ってから、エラーとなった場合のトークンに、対応するアクションが存在するかしないかを、いろいろ調べて、なければラベルerror_popに飛んでいたところでした。
しかし、racc 1.4まで遡っても、cparse.cでは無限ループになりませんでした.
racc1.4は、エラー判定はするものの、それ以降のバージョンのコードと比較して、判定方法はとてもあっさりしていました。
私としては、あんなにしつこくチェックしているから、エラーの判定漏れがないのかなと思っていましたが、文法エラーの時に、（エラー時のアクションが定義されていなければ）ひとつ前の状態にもどるという方針が（今回のようなエラーに対しては）有効のようです。
バージョンを遡って試してみたところ、racc1.3になってやっとcparseでもエラーになることを発見しました.
ただし、1.3といっても1.3.*すべてを試したわけではないので、もっと絞り込む必要があります.