translate_ec(),EC_OPE_ARRAYのバグ修正
cast_expression の実装

識別子から得られる変数のアドレスをスタックに積んで運用するという考え方は、
どうやら正しかったような手応えを見つけた。
正しい方向に歩いているようだ。

構文解析において、expression すなわち実質的に assignment_expression は、
変数をアドレスによる間接参照によって読み書きするか、もしくは
直値(間接参照ではなく、ダイレクトな値)によって読むか、のセクションに分けられて、
これを分ける構文解析のノードは cast_expression となる。
この cast_expression 未満では、変数はアドレスによる間接参照となり、
一方、cast_expression 以上では、変数は直値となる。
(構文解析木のルートを上側、終端記号側を下側として考えた場合)

すなわち、スタックに積まれてることを期待できる値は:
cast_expression 未満では間接参照の為のアドレス
cast_expression 以上では直値
となる。

すなわち、cast_expression の時点で
スタックに積まれてる変数アドレスは、実際の値へと変換される(積み直される)ので、
cast_expression 未満であれば、それは変数への読み書きが可能ということであり、
一方、cast_expression 以上であれば、それは読み込みのみ。が自動的に決定される。
これによって例えば additive_expression 等の、直値として扱うのみの場合において、
スタックからポップすれば、それは何も処理を施さなくとも直値であることが保証される。
非常に見通しがよくなる。

この考察が正しければ、
assignment_expression(代入などの箇所) の左辺は、cast_expression未満であるべきだが、
実際にK&Rのそれでは(簡略して抜粋すると):
assignmet_expression:
    unary_expression = assignment_expression
であり、まさにビンゴである。
(unary_expression は cast_expression の直下の子。
 すなわち"cast_expression未満"の先頭。つまり読み書き可能(代入可能)である)

解釈の方向としては間違えていなかったらしきことが分かって良かった。