sizeof 単項式 — 答えは合っているのに、間違っている

この回の位置づけ

sizeof 式は language_spec.md の外側にある機能である （仕様の「除外機能の一覧」に載っており、代替表は sizeof(型名) で書けと指示している）。 コマ9 の sizeof(型名) を一般化する回で、追加する構文と意味論はこの資料が定義する（次節）。

L 系列の中ではいちばん軽い。字句は 1 文字も変えない（sizeof はコマ9 の時点で すでにキーワードとして読めている）。構文は分岐が 1 つ増えるだけで、 コード生成にいたっては li a0, N の 1 命令で終わる。 それでも、この回でしか出会えない考え方が 1 つある——評価しないという意味論である。

L4 が追加する仕様

language_spec.md の sizeof は型名形式だけである。L4 はそこへ式形式を足す。 以下がこの回で実装すべき言語仕様の追加分であり、check.py / golden.py の 判定はこの定義に従う。

構文

language_spec.md の EBNF の unary_expr に、次の 1 行を足す。

unary_expr ::= …
             | 'sizeof' '(' type_name ')'     /* 既存 */
             | 'sizeof' unary_expr            /* L4 が追加 */

オペランドは unary_expr である（cast_expr の無いこの言語では ISO C の sizeof unary-expression と同じ位置になる）。したがって sizeof は単項演算子で、 sizeof x + 1 は (sizeof x) + 1 と読まれる。

2 つの形式は 'sizeof' の次の 1 トークンだけで見分けられる。

language_spec.md が「type_name は型キーワードで始まるため構文衝突はない」と 書いているのはこのことである。仕様は衝突が無いことを式形式を禁じる根拠に使ったが、 同じ事実は両方を共存させる根拠にもなる。1 トークンの先読みで足りる。

意味論

sizeof e について、次を定める。

1. 結果は e の静的な型のサイズ（バイト数）である。実行時の値には一切依存しない。
2. e は評価されない。 e に含まれる関数呼出し・代入・++/-- などの副作用は 1 つも起こらない。e は型を決めるためだけに使われる。
3. 結果の型は int（language_spec.md の例外 E1 をそのまま引き継ぐ。 本仕様に size_t は無い）。
4. 不完全型・void への sizeof はコンパイルエラーとする。 本体の見えていない struct（前方宣言のみ）と void がこれにあたる （language_spec.md の「未定義動作/エラー」の項目 8 と sizeof(void) の禁止に対応）。 ポインタは指し先が不完全でもサイズ 8 で決まるので、これは通す。
5. 型名形式 sizeof(型名) の意味は変わらない。

L4 を実装しても language_spec.md は変わらない —— 変わるのはあなたのコンパイラが 受理する言語のほうである。

中心にある規則: 評価しない

sizeof は「大きさを測る」演算子だから、まず値を作ってから測るのだと思いたくなる。 しかし C の sizeof は逆である。型だけを見て、値は作らない。

int calls;
int bump() { calls = calls + 1; return 7; }

calls = 0;
n = sizeof bump();      // n は 4。calls は 0 のまま

もしオペランドをコード生成してしまうと、どうなるか。

  call bump          ← 呼ばれてしまう(calls が 1 になる)
  li a0, 4           ← 答えは 4 で「合っている」

n は 4 になる。テストの戻り値だけを見ていると通ってしまう。 それでも仕様違反である。前節で定めたとおり e の副作用は 1 つも起こってはならない。

e は評価されない。 e に含まれる副作用は 1 つも起こらない。

L2 の「複合代入の左辺は 1 回だけ評価される」と同じ形の罠である。 答えが数値として合うことと、意味論として正しいことは別であり、 この回のテスト tests/noeval.c は calls を表示して後者を確かめる。

いまのコンパイラに食わせるとどうなるか

tests/expr.c を標準トラックのコンパイラに渡すと、構文解析で止まる。

構文解析エラー: [line 19] sizeof は sizeof(型名) 形式のみ使えます

スキャフォールドの _parse_sizeof が、'(' + 型キーワードでなければ 明示的にエラーにしている。この回はここに「そうでなければ式形式」を足す。

構文 —— 1 トークンの先読み

ラッパーが用意する部分は次のとおりである。

def _parse_sizeof(self):
    line = self.cur.line
    self.pos += 1                       # 'sizeof'
    if self.cur.sval == '(' and self._peek_is_type():
        ...                             # 従来どおり SizeofType(ty_str=…)
    return Node('SizeofExpr', operand=self._parse_unary(), line=line)

_peek_is_type() は '(' の次のトークンが型キーワードかを見る。 sizeof (a) は a が識別子なので式形式、sizeof (int) は型形式になる。 オペランドを _parse_unary() で読むので、sizeof x + 1 は (sizeof x) + 1 と読まれる（+ は _parse_unary の外側の段にある）。

sizeof c + 1     → Add(SizeofExpr(Var c), Num 1)     = 1 + 1 = 2
sizeof (c + 1)   → SizeofExpr(Add(Var c, Num 1))     = 4

char を使うとこの差が見える（int どうしだと両方 4 になって区別がつかない）。 tests/prec.c はこの形で優先順位を確かめている。

型を辿る —— 評価しない型付け

sizeof に必要なのはオペランドの静的な型である。 土台の mycc.py はすでに _type_of_expr という同じ規則を持っている。 違うのは、こちらは型を知るためだけに木を辿り、命令を 1 行も出さないという点だけである。

Add でポインタを左右どちらでも見るのは、p + 1 と 1 + p の両方が ポインタ型になるからである（コマ9 のスケーリングと同じ非対称性）。 Sub は左だけ見ればよい —— ポインタ同士の引き算は仕様の外にある（発展課題 L1 の題材）。

コード生成 —— 1 命令

型が決まれば、あとは大きさを置くだけである。

cg.emit(f'  li a0, {cg.type_size(ty)}')

;; sizeof *p   (p は int*)
  li a0, 4

codegen はどこにも現れない。この「無い」ことがこの回の実装である。 コード生成の関数が 1 行しかないのに、その 1 行に到達するまでに 型を辿る仕事が要る——sizeof が「実行時ではなく翻訳時の演算子」であることが、 生成コードの形にそのまま出ている。

コマ9 の codegen_SizeofType と比べてほしい。出力は同じ li a0, N で、 違いは N の求め方だけである。型名形式は文字列から直接、式形式は木を辿って求める。

不完全型を弾く

大きさが決まらない型が 2 つある。

土台の size_of_ty_str は知らない型に既定値を返してしまうので、 放っておくと黙って嘘の数が出る。コンパイルエラーで止めるほうが正しい。

[line 12] 不完全型に sizeof は使えません: 'struct FILE'(構造体の本体が見えていない)

ポインタは通す。struct FILE *fp の sizeof fp は 8 で確定する—— 指し先が不完全でも、アドレスの大きさは型に関係なく決まっているからである。 この線引きは C の規則そのままである。

実装

langcc.py はこの 3 つを次の順に呼ぶ。

ty = static_type_of(cg, node.operand)
reject_incomplete(cg, ty, node.line)
gen_sizeof_expr(cg, ty)

Step 1 は場合分けが多いが、1 つずつ check.py を回しながら足していけばよい。 Step 2 は 1 行、Step 3 は 3 行で終わる。

python3 langcc.py tests/noeval.c | grep -c "call bump"   # 1 のはず(sizeof の外の1回だけ)
python3 langcc.py tests/prec.c | grep "li a0, 1"         # sizeof c が 1 で出ている

テスト

python3 check.py     # Step ごとの単体テスト(未実装は SKIP)
python3 golden.py    # sizeof 式のテスト + fixed17

noeval.c が本質である。check.py の Step 2 も同じことを単体で確かめており、 偽のコード生成器で codegen の呼出し回数が 0 回であることを直接見ている。 golden.py の最後で fixed17 を回すのは、型名形式を壊していないことの確認である。

発展課題

1. sizeof の結果を unsigned にしたくなったら: C の sizeof の型は size_t （符号なし）である。本仕様は例外 E1 で int と定めた。もし size_t を入れるなら、 a - b < 0 のような比較がどう変わるかを考える
2. 配列があったら: この言語に配列は無いが、もし int a[10]; を足したら sizeof a は 40 で sizeof &a[0] は 8 になる。「配列はポインタである」という よくある説明が、なぜ sizeof の前で崩れるのかを説明する
3. sizeof の中の宣言: sizeof (struct Point){1, 2} のような複合リテラルは ISO C にはあるが本仕様には無い。_peek_is_type() の先読み 1 トークンで 足りなくなるのはどんな構文か
4. 型検査と組み合わせる（Q1 完了者向け）: sizeof f() で f が void を 返すときにエラーにする。どの情報を Step 1 まで運べばよいか
5. L2 と並べる（L2 完了者向け）: 「左辺は 1 回だけ評価される」と 「オペランドは評価されない」を、コード生成のどこで守っているかで比べる。 片方は codegen_lval の呼び方で、もう片方は codegen を呼ばないことで守っている

この資料の原稿を見る