Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 11334] ファイルの概要

このコミットは、Goコンパイラ（gc）における定数文字列の添字アクセス（subscripting）に関する型チェックの不備を修正するものです。具体的には、定数文字列から特定の文字を抽出する際に、コンパイラが適切な型チェックをスキップしてしまうバグが修正されました。これにより、予期せぬ挙動やコンパイルエラーが発生する可能性がありました。

コミット

commit 93c4e29605ac67f3e288463027c35609ddccc253
Author: Luuk van Dijk <lvd@golang.org>
Date:   Mon Jan 23 16:57:12 2012 +0100

    gc: missed typecheck in subscripting a const string.

    Fixes #2674.

    R=rsc
    CC=golang-dev
    https://golang.org/cl/5574045

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/93c4e29605ac67f3e288463027c35609ddccc253

元コミット内容

Goコンパイラ（gc）において、定数文字列に対する添字アクセス（例: "abc"[0]）の際に、型チェックが適切に行われていなかった問題が修正されました。この問題は、Goの内部バグトラッカーでIssue 2674として報告されていました。

変更の背景

Go言語では、文字列はバイトのシーケンスとして扱われ、添字アクセスによって個々のバイトにアクセスできます。定数文字列の場合、コンパイル時にその値が確定しているため、コンパイラは最適化の一環として、添字アクセスされた定数文字列の値を直接計算し、その結果を定数として扱うことがあります。

しかし、このコミットが修正したバグは、この最適化パスにおいて、計算された結果に対する型チェックが漏れていたことに起因します。具体的には、"abc"[2]のような式が評価される際に、その結果（この場合は'c'のバイト値）が、その後の文脈で期待される型と一致するかどうかの検証が不足していました。これにより、例えばint(dow[1])のように、添字アクセスされた定数文字列のバイト値を別の型にキャストする際に、コンパイラが不正なコードを生成したり、誤った型推論を行ったりする可能性がありました。

このバグは、Goのコンパイラがコードを処理する際の「ウォーク（walk）」フェーズ、特に式を処理するwalkexpr関数内で発生していました。定数文字列の添字アクセスは、コンパイル時にその結果が定数として扱われるべきですが、その定数に対する型チェックが適切に行われていなかったため、潜在的な問題を引き起こしていました。

前提知識の解説

  • Goコンパイラ (gc): Go言語の公式コンパイラです。ソースコードを機械語に変換する役割を担います。コンパイルプロセスは複数のフェーズに分かれており、構文解析、型チェック、最適化、コード生成などがあります。
  • 定数文字列 (Constant String): Go言語において、"hello"のようにリテラルで定義された文字列は定数として扱われます。これらの値はコンパイル時に確定し、実行時に変更されることはありません。
  • 添字アクセス (Subscripting): 配列、スライス、または文字列の特定の要素にアクセスするために使用される操作です。Goの文字列の場合、s[i]のように記述することで、文字列sのi番目のバイトにアクセスできます。
  • 型チェック (Type Checking): プログラムの各部分が、その文脈で期待されるデータ型と一致しているかを検証するプロセスです。型チェックは、プログラムの安全性と正確性を保証するためにコンパイル時に行われます。
  • walkexpr関数: Goコンパイラのgcにおけるwalk.cファイルに存在する関数で、抽象構文木（AST）を「ウォーク」し、式を処理する役割を担います。このフェーズでは、式の評価、最適化、型変換などが行われます。
  • Node構造体: Goコンパイラの内部表現で、抽象構文木の各ノードを表します。各ノードは、式、文、宣言などのプログラム要素に対応し、その型情報や値などの属性を持ちます。
  • n->typecheck = 1;: コンパイラの内部で、特定のノードnに対して型チェックが必要であることを示すフラグを設定する操作です。このフラグが設定されると、コンパイラはそのノードの型が適切であるかを検証します。

技術的詳細

このコミットの技術的詳細は、Goコンパイラのsrc/cmd/gc/walk.cファイル内のwalkexpr関数における変更に集約されます。

walkexpr関数は、Goプログラムの抽象構文木（AST）を走査し、各ノード（式、文など）を処理します。定数文字列の添字アクセス（例: "abc"[2]）のような式がこの関数で処理される際、コンパイラは通常、その結果をコンパイル時定数として評価しようとします。

変更前のコードでは、定数文字列の添字アクセスによって得られた値（例: "abc"[2]の結果である'c'のバイト値）をnodconst関数で定数ノードとして生成した後、そのノードに対する明示的な型チェックが不足していました。

追加された行 n->typecheck = 1; は、この不足を補うものです。

  • nは、定数文字列の添字アクセスによって生成された結果を表すASTノードです。
  • n->typecheck = 1;は、このノードnが後続のコンパイルフェーズで型チェックされる必要があることをコンパイラに指示します。

これにより、"abc"[2]のような式の結果が定数として扱われる場合でも、その定数が使用される文脈において、期待される型と互換性があるかどうかが確実に検証されるようになります。例えば、int(dow[1])のようなキャスト操作がある場合、dow[1]の結果がint型に安全に変換できるかどうかが、このtypecheckフラグによって保証されます。

この修正は、コンパイラの内部的な型システムと定数評価の整合性を高め、Goプログラムのより堅牢なコンパイルを可能にします。

コアとなるコードの変更箇所

変更は主に以下の2つのファイルで行われました。

  1. src/cmd/gc/walk.c: Goコンパイラのウォークフェーズにおける式の処理を担当するファイルです。

    --- a/src/cmd/gc/walk.c
+++ b/src/cmd/gc/walk.c
@@ -876,6 +876,7 @@ walkexpr(Node **np, NodeList **init)
 				// delayed until now because "abc"[2] is not
 				// an ideal constant.
 				nodconst(n, n->type, n->left->val.u.sval->s[v]);
+\t\t\t\tn->typecheck = 1;
 			}
 		}
 	\tgoto ret;

  2. test/fixedbugs/bug399.go: このバグを再現するための新しいテストケースです。

    --- /dev/null
+++ b/test/fixedbugs/bug399.go
@@ -0,0 +1,15 @@
+// $G $D/$F.go || echo "Bug399"
+// Copyright 2011 The Go Authors.  All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+// Issue 2674
+package main
+const dow = "\000\003"
+func main() {
+	println(int(dow[1]))
+}

コアとなるコードの解説

src/cmd/gc/walk.c の変更

walkexpr関数内の変更は、定数文字列の添字アクセスが処理される特定のコードブロック内で行われています。このブロックは、"abc"[2]のような式が「理想的な定数」ではないため、その評価が遅延されるケースを扱っています。

変更前のコードでは、nodconst(n, n->type, n->left->val.u.sval->s[v]);によって、添字アクセスされた定数文字列のバイト値（n->left->val.u.sval->s[v]）が新しい定数ノードnとして生成されていました。しかし、この生成された定数ノードnに対して、その後のコンパイルフェーズで型チェックが適切に行われることを保証するフラグが設定されていませんでした。

追加された行 n->typecheck = 1; は、この問題を解決します。この行は、新しく生成された定数ノードnに対して、typecheckフラグを1に設定します。これにより、コンパイラは、このノードが使用される際に、その型が文脈的に正しいかどうかを強制的に検証するようになります。例えば、int(dow[1])のように、バイト値をintにキャストするような場合でも、このフラグによって適切な型チェックがトリガーされ、コンパイル時のエラーや予期せぬ挙動を防ぐことができます。

test/fixedbugs/bug399.go の追加

このテストケースは、修正されたバグを具体的に再現するために作成されました。

package main
const dow = "\000\003"

func main() {
	println(int(dow[1]))
}
  • const dow = "\000\003": ヌル文字（\000）とASCIIコード3（\003、End of Text文字）を含む2バイトの定数文字列dowを定義しています。
  • println(int(dow[1])): dow文字列のインデックス1にあるバイト（つまり\003）にアクセスし、そのバイト値をint型にキャストして出力しています。

変更前のコンパイラでは、dow[1]の評価結果（バイト値3）が定数として扱われる際に、その後のint()へのキャストに対する型チェックが適切に行われなかった可能性があります。これにより、コンパイラが誤ったコードを生成したり、コンパイルエラーを報告しなかったりするバグが発生していました。このテストケースは、この特定のシナリオを捕捉し、修正が正しく機能することを確認するために使用されます。

関連リンク

  • Go言語のIssueトラッカー (内部): このコミットが修正したIssue 2674は、Goプロジェクトの内部バグトラッカーで管理されていた可能性があります。
  • Go言語のコンパイラソースコード: src/cmd/gc/ ディレクトリには、Goコンパイラの主要なソースコードが含まれています。

参考にした情報源リンク

  • Go言語の公式ドキュメント: https://golang.org/doc/
  • Go言語のソースコードリポジトリ: https://github.com/golang/go
  • Go言語のコンパイラ設計に関する資料 (一般的な情報源): Goコンパイラの内部構造や動作に関する情報は、公式ブログやGoのカンファレンス発表などで公開されていることがあります。
  • Go言語のIssue 2674 (CL 5574045): https://golang.org/cl/5574045 (このリンクはコミットメッセージに記載されており、GoのコードレビューシステムGerritへのリンクです。)