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

このコミットは、Go言語の初期段階におけるコンパイラの挙動、特に配列の境界チェックに関する興味深い「回避策」を示しています。test/ken/array.goというテストファイル内の特定のコード行が変更され、コンパイラが静的に検出する境界外アクセスを動的なインデックス参照に切り替えることで回避しています。これは、当時のコンパイラの最適化や静的解析の限界、あるいは意図的な設計によるものと考えられます。

コミット

• コミットハッシュ: 3489fe958e5b03d755c81e8d3d24c8f5feaf7c16
• 作者: Rob Pike r@golang.org
• コミット日時: Mon Nov 24 16:23:49 2008 -0800

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

https://github.com/golang/go/commit/3489fe958e5b03d755c81e8d3d24c8f5feaf7c16

元コミット内容

compiler catches out of bounds; work around

R=ken
OCL=19943
CL=19943

変更の背景

このコミットの背景には、Go言語の非常に初期のコンパイラの挙動が関係しています。コミットメッセージ「compiler catches out of bounds; work around」が示す通り、当時のGoコンパイラは、配列へのアクセスがコンパイル時に境界外であると静的に判断できる場合に、そのコードをエラーとして検出していました。

具体的には、a[80] = 0; のようにリテラル値で配列のインデックスを指定した場合、コンパイラは配列aの宣言（例えばvar a [10]intのような場合）と照らし合わせて、インデックス80が配列の有効な範囲（0から9まで）を超えていることをコンパイル時に検出し、エラーを発生させていたと考えられます。

しかし、開発者は意図的に境界外アクセスをテストしたい、あるいは特定の挙動を確認したい場合があります。このコミットは、コンパイラの静的な境界チェックを回避し、実行時に境界外アクセスを発生させるための「回避策」を導入しています。これは、コンパイラがリテラル値ではなく変数によるインデックス参照の場合には、その値が実行時まで確定しないため、静的な境界チェックを適用できないという特性を利用したものです。

この変更は、Go言語のコンパイラが進化する過程で、静的解析と実行時挙動のバランスをどのように取っていたかを示す貴重な例と言えます。

前提知識の解説

配列の境界チェック (Array Bounds Checking)

配列の境界チェックとは、プログラムが配列の要素にアクセスしようとするときに、指定されたインデックスが配列の有効な範囲内にあるかどうかを確認するプロセスです。

• 静的境界チェック: コンパイル時に行われるチェックです。コンパイラが、コード内の配列アクセスが常に有効な範囲内にあるか、あるいは常に範囲外にあるかを判断できる場合に適用されます。例えば、arr[10]というアクセスがあり、arrがサイズ10の配列（インデックス0-9）である場合、コンパイラはこれが境界外アクセスであることを静的に検出できます。
• 動的境界チェック (実行時境界チェック): プログラムの実行時に行われるチェックです。インデックスが変数によって指定される場合など、コンパイル時にはその値が確定しないため、実行時にインデックスが有効な範囲内にあるかどうかが確認されます。もしインデックスが範囲外であれば、通常は「インデックス範囲外エラー (Index Out Of Bounds Error)」や「セグメンテーション違反 (Segmentation Fault)」などの実行時エラーが発生し、プログラムが異常終了します。

Go言語は、安全なメモリ管理と堅牢なプログラミングを促進するため、デフォルトで実行時境界チェックを行います。これにより、C/C++のような言語でよく見られる境界外アクセスによる未定義動作やセキュリティ脆弱性を防ぐことができます。

Go言語の初期のコンパイラ

Go言語は2009年に一般公開されましたが、このコミットは2008年に行われています。これはGo言語がまだ開発の初期段階にあったことを意味します。初期のコンパイラは、現在のGoコンパイラに比べて最適化や静的解析の能力が限定的であった可能性があります。

この時期のコンパイラは、リテラル値による配列アクセスに対しては厳密な静的境界チェックを適用していた一方で、変数によるアクセスに対しては、その変数の値が実行時まで不明であるため、静的なチェックをスキップしていたと考えられます。この挙動は、コンパイラの設計や最適化戦略に依存します。

技術的詳細

このコミットの技術的な核心は、Goコンパイラの静的解析の限界を「利用」して、意図的に実行時エラーを発生させるためのコード変更にあります。

元のコードは以下の通りでした。

a[80] = 0;

ここでaが例えば[10]intのような配列であった場合、インデックス80は明らかに配列の境界（0から9）を超えています。Goの初期コンパイラは、このようなリテラル値による境界外アクセスをコンパイル時に検出し、エラーとして処理していました。これは、コンパイラがコードを解析する際に、80という値が配列aのサイズを超えていることを容易に判断できるためです。

しかし、テストの目的などで、この境界外アクセスがコンパイル時にエラーとなるのではなく、実行時に実際にパニック（Goにおける実行時エラー）として発生することを期待する場合があります。

そこで、コミットでは以下のように変更されました。

x := 80;
a[x] = 0;

この変更により、インデックス80が直接リテラルとしてa[...]に渡されるのではなく、一度変数xに代入されてから、その変数xがインデックスとして使用されます。

Goの初期コンパイラは、変数の値がコンパイル時に確定しない場合（特に、変数が複雑な計算結果や外部入力に依存する可能性がある場合）、その変数を介した配列アクセスに対しては静的な境界チェックを行わない傾向がありました。代わりに、このようなアクセスは実行時に境界チェックが行われることになります。

したがって、この変更によって、コンパイル時にはエラーが発生せず、プログラムが実行された際にa[x]（xは80）のアクセスが実際に境界外であると判断され、実行時パニックが発生するようになります。これは、コンパイラの静的解析を「回避」し、動的な挙動をテストするための典型的な手法です。

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

--- a/test/ken/array.go
+++ b/test/ken/array.go
@@ -139,7 +139,8 @@ testfdfault()
 		a[i] = 0;
 	}
 	print("should fault\n");
-	a[80] = 0;
+	x := 80;
+	a[x] = 0;
 	print("bad\n");
 }

コアとなるコードの解説

変更されたのはtest/ken/array.goファイルのtestfdfault()関数内の一部分です。

• 変更前:

  a[80] = 0;
  

  この行は、配列aのインデックス80に値0を代入しようとしています。もし配列aのサイズが80未満であれば、これは境界外アクセスとなります。Goの初期コンパイラは、80というリテラル値が配列の宣言されたサイズを超えていることを静的に検出し、コンパイルエラーを発生させていました。print("should fault\\n");という行が直前にあることから、このコードは本来、実行時に「fault」（パニック）することを期待して書かれていたと考えられます。しかし、コンパイル時にエラーになるため、期待通りのテストができていませんでした。

• 変更後:

  x := 80;
  a[x] = 0;
  

  この変更では、リテラル値80を直接配列のインデックスとして使う代わりに、まず変数xに80を代入し、その変数xをインデックスとして使用しています。 Goの初期コンパイラは、変数を介した配列アクセスの場合、その変数の値がコンパイル時に確定できないと判断し、静的な境界チェックを行いませんでした。これにより、このコードはコンパイルエラーにならずにビルドが成功します。そして、プログラムが実行されると、xの値は80であるため、a[80]へのアクセスが実際に発生し、配列aのサイズが80未満であれば、実行時に境界外アクセスによるパニックが発生します。 この「回避策」により、開発者はコンパイラの静的チェックを迂回し、実行時の境界外アクセス挙動をテストできるようになりました。

関連リンク

• Go言語の公式ドキュメント (現在のバージョン): https://go.dev/doc/
• Go言語の歴史に関する情報 (初期の設計思想など): https://go.dev/blog/

参考にした情報源リンク

• Go言語のコミット履歴 (GitHub): https://github.com/golang/go/commits/master
• Go言語の配列とスライスに関するドキュメント: https://go.dev/blog/go-slices-usage-and-internals (これは現在のGoの挙動に関するものですが、境界チェックの概念は共通です)
• Go言語のコンパイラに関する一般的な情報 (初期の挙動に特化した公開情報は少ないため、一般的なコンパイラの静的解析の概念を参考にしています)

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

このコミットは、Go言語の初期段階におけるコンパイラの挙動、特に配列の境界チェックに関する興味深い「回避策」を示しています。test/ken/array.goというテストファイル内の特定のコード行が変更され、コンパイラが静的に検出する境界外アクセスを動的なインデックス参照に切り替えることで回避しています。これは、当時のコンパイラの最適化や静的解析の限界、あるいは意図的な設計によるものと考えられます。

コミット

• コミットハッシュ: 3489fe958e5b03d755c81e8d3d24c8f5feaf7c16
• 作者: Rob Pike r@golang.org
• コミット日時: Mon Nov 24 16:23:49 2008 -0800

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

https://github.com/golang/go/commit/3489fe958e5b03d755c81e8d3d24c8f5feaf7c16

元コミット内容

compiler catches out of bounds; work around

R=ken
OCL=19943
CL=19943

変更の背景

このコミットの背景には、Go言語の非常に初期のコンパイラの挙動が関係しています。コミットメッセージ「compiler catches out of bounds; work around」が示す通り、当時のGoコンパイラは、配列へのアクセスがコンパイル時に境界外であると静的に判断できる場合に、そのコードをエラーとして検出していました。

具体的には、a[80] = 0; のようにリテラル値で配列のインデックスを指定した場合、コンパイラは配列aの宣言（例えばvar a [10]intのような場合）と照らし合わせて、インデックス80が配列の有効な範囲（0から9まで）を超えていることをコンパイル時に検出し、エラーを発生させていたと考えられます。

しかし、開発者は意図的に境界外アクセスをテストしたい、あるいは特定の挙動を確認したい場合があります。このコミットは、コンパイラの静的な境界チェックを回避し、実行時に境界外アクセスを発生させるための「回避策」を導入しています。これは、コンパイラがリテラル値ではなく変数によるインデックス参照の場合には、その値が実行時まで確定しないため、静的な境界チェックを適用できないという特性を利用したものです。

この変更は、Go言語のコンパイラが進化する過程で、静的解析と実行時挙動のバランスをどのように取っていたかを示す貴重な例と言えます。

前提知識の解説

配列の境界チェック (Array Bounds Checking)

配列の境界チェックとは、プログラムが配列の要素にアクセスしようとするときに、指定されたインデックスが配列の有効な範囲内にあるかどうかを確認するプロセスです。

• 静的境界チェック: コンパイル時に行われるチェックです。コンパイラが、コード内の配列アクセスが常に有効な範囲内にあるか、あるいは常に範囲外にあるかを判断できる場合に適用されます。例えば、arr[10]というアクセスがあり、arrがサイズ10の配列（インデックス0-9）である場合、コンパイラはこれが境界外アクセスであることを静的に検出できます。
• 動的境界チェック (実行時境界チェック): プログラムの実行時に行われるチェックです。インデックスが変数によって指定される場合など、コンパイル時にはその値が確定しないため、実行時にインデックスが有効な範囲内にあるかどうかが確認されます。もしインデックスが範囲外であれば、通常は「インデックス範囲外エラー (Index Out Of Bounds Error)」や「セグメンテーション違反 (Segmentation Fault)」などの実行時エラーが発生し、プログラムが異常終了します。

Go言語は、安全なメモリ管理と堅牢なプログラミングを促進するため、デフォルトで実行時境界チェックを行います。これにより、C/C++のような言語でよく見られる境界外アクセスによる未定義動作やセキュリティ脆弱性を防ぐことができます。

Go言語の初期のコンパイラ

Go言語は2009年に一般公開されましたが、このコミットは2008年に行われています。これはGo言語がまだ開発の初期段階にあったことを意味します。初期のコンパイラは、現在のGoコンパイラに比べて最適化や静的解析の能力が限定的であった可能性があります。

この時期のコンパイラは、リテラル値による配列アクセスに対しては厳密な静的境界チェックを適用していた一方で、変数によるアクセスに対しては、その変数の値が実行時まで不明であるため、静的なチェックをスキップしていたと考えられます。この挙動は、コンパイラの設計や最適化戦略に依存します。

技術的詳細

このコミットの技術的な核心は、Goコンパイラの静的解析の限界を「利用」して、意図的に実行時エラーを発生させるためのコード変更にあります。

元のコードは以下の通りでした。

a[80] = 0;

ここでaが例えば[10]intのような配列であった場合、インデックス80は明らかに配列の境界（0から9）を超えています。Goの初期コンパイラは、このようなリテラル値による境界外アクセスをコンパイル時に検出し、エラーとして処理していました。これは、コンパイラがコードを解析する際に、80という値が配列aのサイズを超えていることを容易に判断できるためです。

しかし、テストの目的などで、この境界外アクセスがコンパイル時にエラーとなるのではなく、実行時に実際にパニック（Goにおける実行時エラー）として発生することを期待する場合があります。

そこで、コミットでは以下のように変更されました。

x := 80;
a[x] = 0;

この変更により、インデックス80が直接リテラルとしてa[...]に渡されるのではなく、一度変数xに代入されてから、その変数xがインデックスとして使用されます。

Goの初期コンパイラは、変数の値がコンパイル時に確定しない場合（特に、変数が複雑な計算結果や外部入力に依存する可能性がある場合）、その変数を介した配列アクセスに対しては静的な境界チェックを行わない傾向がありました。代わりに、このようなアクセスは実行時に境界チェックが行われることになります。

したがって、この変更によって、コンパイル時にはエラーが発生せず、プログラムが実行された際にa[x]（xは80）のアクセスが実際に境界外であると判断され、実行時パニックが発生するようになります。これは、コンパイラの静的解析を「回避」し、動的な挙動をテストするための典型的な手法です。

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

--- a/test/ken/array.go
+++ b/test/ken/array.go
@@ -139,7 +139,8 @@ testfdfault()
 		a[i] = 0;
 	}
 	print("should fault\n");
-	a[80] = 0;
+	x := 80;
+	a[x] = 0;
 	print("bad\n");
 }

コアとなるコードの解説

変更されたのはtest/ken/array.goファイルのtestfdfault()関数内の一部分です。

• 変更前:

  a[80] = 0;
  

  この行は、配列aのインデックス80に値0を代入しようとしています。もし配列aのサイズが80未満であれば、これは境界外アクセスとなります。Goの初期コンパイラは、80というリテラル値が配列の宣言されたサイズを超えていることを静的に検出し、コンパイルエラーを発生させていました。print("should fault\\n");という行が直前にあることから、このコードは本来、実行時に「fault」（パニック）することを期待して書かれていたと考えられます。しかし、コンパイル時にエラーになるため、期待通りのテストができていませんでした。

• 変更後:

  x := 80;
  a[x] = 0;
  

  この変更では、リテラル値80を直接配列のインデックスとして使う代わりに、まず変数xに80を代入し、その変数xをインデックスとして使用しています。 Goの初期コンパイラは、変数を介した配列アクセスの場合、その変数の値がコンパイル時に確定できないと判断し、静的な境界チェックを行いませんでした。これにより、このコードはコンパイルエラーにならずにビルドが成功します。そして、プログラムが実行されると、xの値は80であるため、a[80]へのアクセスが実際に発生し、配列aのサイズが80未満であれば、実行時に境界外アクセスによるパニックが発生します。 この「回避策」により、開発者はコンパイラの静的チェックを迂回し、実行時の境界外アクセス挙動をテストできるようになりました。

関連リンク

• Go言語の公式ドキュメント (現在のバージョン): https://go.dev/doc/
• Go言語の歴史に関する情報 (初期の設計思想など): https://go.dev/blog/

参考にした情報源リンク

• Go言語のコミット履歴 (GitHub): https://github.com/golang/go/commits/master
• Go言語の配列とスライスに関するドキュメント: https://go.dev/blog/go-slices-usage-and-internals (これは現在のGoの挙動に関するものですが、境界チェックの概念は共通です)
• Go言語のコンパイラに関する一般的な情報 (初期の挙動に特化した公開情報は少ないため、一般的なコンパイラの静的解析の概念を参考にしています)