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

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

このコミットは、GoランタイムにおけるPlan 9環境でのコンパイル時の警告を修正するものです。具体的には、src/pkg/runtime/mgc0.cファイル内のruntime·printf関数のフォーマット指定子が原因で発生していた警告を解消しています。

コミット

commit fb5e1e1fa181f658431ef2c12fa2ccef5f728bdf
Author: David du Colombier <0intro@gmail.com>
Date:   Thu Mar 6 20:56:22 2014 +0100

    runtime: fix warnings on Plan 9
    
    warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 2
    warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 3
    
    LGTM=bradfitz
    R=golang-codereviews, bradfitz
    CC=golang-codereviews
    https://golang.org/cl/71950044

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

https://github.com/golang/go/commit/fb5e1e1fa181f658431ef2c12fa2ccef5f728bdf

元コミット内容

runtime: fix warnings on Plan 9
    
warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 2
warning: pkg/runtime/mgc0.c:2352 format mismatch p UVLONG, arg 3

変更の背景

このコミットは、GoランタイムをPlan 9オペレーティングシステム上でコンパイルする際に発生していた特定の警告を修正するために行われました。警告メッセージ「format mismatch p UVLONG, arg 2」および「format mismatch p UVLONG, arg 3」が示すように、src/pkg/runtime/mgc0.cファイルの2352行目にあるruntime·printf関数の呼び出しにおいて、フォーマット指定子と引数の型が一致していないことが問題でした。

Goランタイムは、様々なアーキテクチャやオペレーティングシステムをサポートするように設計されています。しかし、各プラットフォームには独自の特性やCコンパイラの挙動の違いが存在します。Plan 9は、その独特な設計思想を持つオペレーティングシステムであり、標準Cライブラリのprintf関数の実装や、特定の型（この場合はUVLONG、すなわちunsigned long long）の扱いにおいて、他の一般的なUnix系システムとは異なる厳密性や解釈を持つことがあります。

この警告は、Goランタイムが内部で使用するruntime·printf（これは標準Cライブラリのprintfとは異なる、Goランタイム独自の軽量な実装です）が、UVLONG型の引数に対してポインタ型（%p）のフォーマット指定子を使用していたために発生しました。これは、メモリ統計情報（mstats.heap_allocなど）を表示する際に、これらの値が非常に大きな数値であるにもかかわらず、ポインタとして解釈されようとしていたことを意味します。Plan 9のコンパイラは、この型ミスマッチを厳密に検出し、警告として報告していました。開発者は、この警告を解消し、コードの移植性と堅牢性を向上させる必要がありました。

前提知識の解説

1. Goランタイム (Go Runtime)

Goランタイムは、Goプログラムの実行を管理する低レベルのコンポーネントです。これには、ガベージコレクション（GC）、スケジューラ（ゴルーチンの管理）、メモリ割り当て、システムコールインターフェースなどが含まれます。Goプログラムは、コンパイル時にこのランタイムとリンクされ、独立したバイナリとして実行されます。src/pkg/runtime/ディレクトリには、このランタイムのソースコードが含まれており、C言語（またはGoの内部的なCライクな言語）とアセンブリ言語で書かれています。

2. ガベージコレクション (Garbage Collection, GC)

ガベージコレクションは、プログラムが動的に割り当てたメモリのうち、もはや使用されていない（参照されていない）領域を自動的に解放するプロセスです。Goはトレース型ガベージコレクタを採用しており、プログラムが実行中に到達可能なオブジェクトを追跡し、到達不可能なオブジェクトを「ガベージ」として回収します。mgc0.cというファイル名は、"memory garbage collection"に関連するコードであることを示唆しています。

3. printf関数とフォーマット指定子

printfは、C言語の標準ライブラリ関数であり、フォーマットされた文字列を標準出力に出力するために使用されます。フォーマット文字列には、プレーンテキストと、引数の値を挿入するための「フォーマット指定子」が含まれます。

主要なフォーマット指定子には以下のようなものがあります。

  • %d または %i: 符号付き10進整数
  • %u: 符号なし10進整数
  • %f: 浮動小数点数
  • %s: 文字列
  • %c: 文字
  • %p: ポインタのアドレス（通常は16進数で表示）
  • %x または %X: 符号なし16進整数

4. Plan 9オペレーティングシステム

Plan 9 from Bell Labsは、Unixの後継として設計された分散オペレーティングシステムです。その設計哲学は、すべてのリソースをファイルとして表現し、それらをネットワークを通じて透過的にアクセス可能にすることに重点を置いています。Plan 9は、そのシンプルさ、モジュール性、そしてネットワーク透過性で知られています。しかし、その独自の設計のため、他のUnix系システムとは異なるAPIやツールの挙動を持つことがあります。特に、Cコンパイラや標準ライブラリの実装には、細かな違いが存在し、それが移植性の問題を引き起こすことがあります。

5. UVLONG型

UVLONGは、Plan 9のC言語環境で使われる型定義で、unsigned long longに相当します。これは、非常に大きな符号なし整数値を格納するために使用されます。Goランタイムのメモリ統計情報（mstats.heap_allocなど）は、システムの総ヒープ割り当て量など、非常に大きなバイト数を表すため、このUVLONG型（またはそれに相当するuint64など）で表現されるのが一般的です。

技術的詳細

このコミットの核心は、runtime·printf関数におけるフォーマット指定子の誤用です。Goランタイムは、標準Cライブラリに依存しない独自のprintf実装を持っています。これは、ランタイムが非常に低レベルで動作し、OSのブートストラップや初期化の段階で標準ライブラリがまだ利用できない可能性があるためです。

問題の行は以下の通りでした。

runtime·printf("runtime: mstats skew: heap=%p/%p\\n", heap1, mstats.heap_alloc);

ここで、heap1とmstats.heap_allocは、Goランタイムのメモリ統計構造体mstatsから取得される値であり、通常はuint64（またはPlan 9環境ではUVLONG）のような大きな符号なし整数型で、メモリのバイト数を表します。

しかし、%pフォーマット指定子は、ポインタのアドレスを表示するために設計されています。ポインタは通常、メモリ上の特定の位置を指すアドレスであり、その内部表現はシステムによって異なりますが、一般的にはvoid*型として扱われます。UVLONGのような整数値を%pで出力しようとすると、コンパイラは型ミスマッチを検出し、警告を発します。これは、コンパイラが、ポインタとして解釈されるべきではない整数値がポインタとして扱われていることを指摘しているためです。

Plan 9のCコンパイラは、この型ミスマッチに対して特に厳密であったため、警告が発生しました。他のシステムでは、このような型ミスマッチが警告されないか、あるいは異なる警告メッセージが表示されることもあります。

修正は、%pを%Dに変更することによって行われました。

runtime·printf("runtime: mstats skew: heap=%D/%D\\n", heap1, mstats.heap_alloc);

Plan 9のC言語環境におけるprintfの慣習では、%Dはlong longまたはunsigned long long（すなわちUVLONG）のような大きな整数型を表示するためのフォーマット指定子として使用されます。この変更により、runtime·printfはheap1とmstats.heap_allocの値を、それらが本来持つUVLONG型として正しく解釈し、出力するようになりました。これにより、コンパイラの型チェックがパスし、警告が解消されました。

この修正は、Goランタイムのクロスプラットフォーム互換性を維持し、特定の環境でのコンパイルエラーや警告を排除するために重要です。警告は必ずしもプログラムのクラッシュを意味するわけではありませんが、潜在的なバグや未定義の動作を示唆する可能性があり、クリーンなビルドはソフトウェアの品質と信頼性を高めます。

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

変更はsrc/pkg/runtime/mgc0.cファイルの一箇所のみです。

--- a/src/pkg/runtime/mgc0.c
+++ b/src/pkg/runtime/mgc0.c
@@ -2349,7 +2349,7 @@ gc(struct gc_args *args)
 		heap1 = mstats.heap_alloc;
 		updatememstats(&stats);
 		if(heap1 != mstats.heap_alloc) {
-			runtime·printf("runtime: mstats skew: heap=%p/%p\\n", heap1, mstats.heap_alloc);
+			runtime·printf("runtime: mstats skew: heap=%D/%D\\n", heap1, mstats.heap_alloc);
 			runtime·throw("mstats skew");
 		}
 		obj = mstats.nmalloc - mstats.nfree;

コアとなるコードの解説

変更された行は、Goランタイムのガベージコレクション（GC）プロセスの一部であるgc関数内にあります。この特定のコードブロックは、メモリ統計（mstats）の整合性をチェックしています。

heap1とmstats.heap_allocは、ガベージコレクションの前後でヒープの割り当て量が一致するかどうかを確認するために使用される変数です。もし一致しない場合（heap1 != mstats.heap_alloc）、それはメモリ統計に「スキュー（歪み）」が発生していることを意味し、ランタイムは致命的なエラーとしてruntime·throw("mstats skew")を呼び出します。

変更前のコードでは、このエラーメッセージを出力する際に、runtime·printf関数で%pというフォーマット指定子を使用していました。

runtime·printf("runtime: mstats skew: heap=%p/%p\\n", heap1, mstats.heap_alloc);

ここで、heap1とmstats.heap_allocは、Goランタイムの内部でメモリサイズを表すuint64（またはPlan 9環境ではUVLONG）型の値です。%pはポインタのアドレスを出力するための指定子であり、整数値を渡すと型ミスマッチが発生します。Plan 9のコンパイラはこれを警告として報告していました。

変更後のコードでは、%pが%Dに修正されました。

runtime·printf("runtime: mstats skew: heap=%D/%D\\n", heap1, mstats.heap_alloc);

%Dは、Plan 9のC言語環境におけるprintfの慣習において、long longまたはunsigned long long（UVLONG）のような大きな整数型を10進数で出力するための正しいフォーマット指定子です。この変更により、heap1とmstats.heap_allocの値が、それらの実際の型（大きな符号なし整数）として正しく解釈され、出力されるようになりました。これにより、コンパイラの警告が解消され、コードの正確性と移植性が向上しました。

この修正は、機能的な変更ではなく、コンパイル時の警告を解消し、コードのクリーンさを保つためのものです。しかし、このような細かな修正が、異なるプラットフォームでのGoランタイムの安定した動作を保証するために不可欠です。

関連リンク

参考にした情報源リンク

  • Go言語のソースコード (特にsrc/pkg/runtime/ディレクトリ)
  • C言語のprintf関数のドキュメント
  • Plan 9オペレーティングシステムに関する情報
  • Go言語のガベージコレクションに関するドキュメント
  • Go言語のクロスコンパイルとプラットフォームサポートに関する情報I have provided the detailed technical explanation of the commit in Markdown format, following all the specified instructions and chapter structure. The output is sent to standard output only.