テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(macro-of-inline) 最後の罠

macro-of-inlineのモチベーションはこうであった.

世の中には糞みたいなコンパイラがある. それらはinliningをサポートしていない. ならばプリプロセッサとしてinliningを実装してやる.

私の脳内では以下がうまくいくはずであった.

  1. gccプリプロセシングする.
  2. macro-of-inlineに通す.
  3. 出てきたものを糞コンパイラに渡す.

しかしよく考えてみると, gccプリプロセシングした時点で, gccのincludeファイルを使ってしまっているし, macro-of-inlineから出てきたものにもそれが含まれてしまっている. そして, それらincludeファイルに入ってる型定義だとかは, pycparserがパースするために必要である(そもそもこれが誤ってる感があるが, 仮にこれがなくても問題はなくならない). 従って, 糞コンパイラはそれをコンパイル出来てしまうかも知れないが, 一般に正しく動かない.

これは悲劇だ. macro-of-inlineを実装し始めたのが先週の土曜日, それから水曜日までみっちりと5日間使って実装・デバッグをした. デバッグはとても大変だったが, やっと, 「結構大きなファイルに対して適用して動くようになった」というレベルまで辿りつけた.

悲劇だ. このままではmacro-of-inlineはただのゴミになってしまう. 違う, そこそこ有用なソフトウェアのはずなのだ.

もし, 糞コンパイラプリプロセッサを分離していれば, まだ救いはある. しかし出来れば, 糞コンパイラに渡すまではずっと得意な世界でやりたいのだ(つまりLinuxのことだ). 私の脳内で描いたように出来れば最高だ.

今私は道を探している. pycparserが提供するfake_libc_includeは, 何の役に立ちそうもないのだが, 私が見落としているだけかも知れない.

例えば, 以下のようなことが出来れば最高

  1. fake_libc_includeを使ってプリプロセシング, macro-of-inlineまで実行する.
  2. その時には, もとのファイルに対して, ディレクティブやmacroの展開がされているが, include文のみは元のままである. そして, fake_libc_include由来のものはすべて消え失せている.
  3. そいつを糞コンパイラに通す. コンパイル出来て実行出来る.

正規表現を使うというのが一つの手だと思うが, 私は正規表現があまり好きではない. 不完全だからだ. なにか, gccのオプションを使ったり, 公式なライブラリを使ったり, 出来るだけ正道っぽい処理の組み合わせで上記妄想を実現したい.

私は明日金曜日を含み, 3日間休む. たぶん色々と試行錯誤することになるだろう.