Day 045 — unsafeパッケージの基礎（概念編: 安全性を捨てる4つの場面と代償）

📚 背景知識（読んでから問題へ）

Day 043〜044ではreflectパッケージを扱い、「型安全性の保証をコンパイル時から実行時に後退させる」代償を学びました。reflectは代償を払いつつも、メモリ安全性そのものは保ち続けます（CanSet()がfalseのフィールドへの書き込みは、メモリを壊す代わりにpanicします）。今回のテーマunsafeパッケージは、さらに一段踏み込み、メモリ安全性そのものをコンパイラ・ランタイムの保護から外す仕組みです。

Goの通常のポインタ（*T）は必ず特定の型Tに紐づいており、コンパイラは「*intを*stringとして扱う」ような操作を型エラーとして拒否します。この制約のおかげで、Goのプログラムは（データ競合を除けば）メモリ破壊を起こしにくい設計になっています。しかし現実には、この制約の外側でしか実現できない処理が存在します。

• OSのシステムコール（syscallパッケージ）に、Goの型を持たない生のメモリアドレスを渡す
• C言語のライブラリとメモリを共有する（cgo）
• コピーを避けて[]byteとstringを相互変換する（ゼロコピー変換）
• 構造体のメモリレイアウト（フィールドのオフセット・パディング）を検査する

unsafe.Pointerは、これらの場面のために用意された「型を持たない生ポインタ」です。unsafeというパッケージ名そのものが、「ここから先はコンパイラがあなたを守れません」という明示的な警告になっている点が、Goの設計思想（暗黙の危険より明示的な警告）らしいところです。

📝 問題

以下の5つの問いに答えてください。(2)と(3)はgo run main.goでそのまま実行できる完全なコードを提示すること。

1. unsafe.Pointerは通常の*Tと何が違うのか。また、なぜGoの型安全性の原則から見て「特別扱い」されているのかを説明してください。
2. []byteをコピーせずにstringに変換する（ゼロコピー変換）ユースケースについて、通常のstring(b)変換と比較したときのパフォーマンス上の利点と、それによって破られる不変条件（Goのstringが暗黙に前提としている性質）を説明した上で、unsafe.String・unsafe.SliceData（Go 1.20+）を使った変換関数を実装し、その不変条件が実際に破られる様子をmain関数で実演してください。
3. unsafe.Sizeofとunsafe.Offsetofを使い、構造体のフィールドの並び順を変えるとメモリサイズがどう変わるか（パディングの発生）を実際に確認するコードを書いてください。
4. 「unsafe.Pointerをuintptrに変換し、何らかの演算をしてから再びunsafe.Pointerに戻す」というパターンを、複数の文に分けて書くことがなぜ危険なのか、Goのガベージコレクションおよびgoroutineのスタック伸長の仕組みと関連づけて説明してください（このパターンのコードを実際に書く必要はありません）。
5. reflect（Day 043〜044）とunsafeは、どちらも「型安全性のコンパイル時保証を手放す」という点で似ていますが、両者が実際に手放しているものの違いは何かを説明してください。

🔍 ヒント（段階的開示）

📋 コピーpackage main

import (
	"fmt"
	"unsafe"
)

func BytesToStringUnsafe(b []byte) string {
	if len(b) == 0 {
		return ""
	}
	return unsafe.String(unsafe.SliceData(b), len(b))
}

type BadOrder struct {
	A bool
	B int64
	C bool
}

func main() {
	b := []byte("hello")
	s := BytesToStringUnsafe(b)
	fmt.Println(s)
	// b を書き換えると s はどうなるか？ 実際に試してみる

	var bo BadOrder
	fmt.Println(unsafe.Sizeof(bo)) // 期待した値と一致するか？
}

✅ 模範解答

main.go（(2) ゼロコピー変換と不変条件の破壊の実演）

📋 コピーpackage main

import (
	"fmt"
	"unsafe"
)

// BytesToStringUnsafe は b をコピーせずに string に変換する。
// 戻り値の string は b と同じメモリ領域（配列）を指す。
// Go の string は「一度作られたら中身は変わらない」ことが言語仕様レベルで
// 保証されている前提だが、この関数が返す string はその前提を満たさない。
// 呼び出し後に元の b を書き換えると、変換済みの string の中身も一緒に変わる。
func BytesToStringUnsafe(b []byte) string {
	if len(b) == 0 {
		return ""
	}
	return unsafe.String(unsafe.SliceData(b), len(b))
}

// StringToBytesUnsafe は s をコピーせずに []byte に変換する。
// こちらはさらに危険: 戻り値の []byte を書き換えると、
// 本来書き換え不可能なはずの元の string の中身が書き換わる。
// s がGoの文字列リテラル（読み取り専用メモリに配置されうる）の場合、
// 書き込もうとすると実行時にクラッシュする可能性がある。
func StringToBytesUnsafe(s string) []byte {
	if len(s) == 0 {
		return nil
	}
	return unsafe.Slice(unsafe.StringData(s), len(s))
}

func main() {
	fmt.Println("--- ゼロコピー変換: b と s がメモリを共有することの実演 ---")
	b := []byte("hello, unsafe")
	s := BytesToStringUnsafe(b)
	fmt.Println("変換直後の s:", s)

	b[0] = 'H' // b を書き換える
	fmt.Println("b[0]='H' に書き換えた後の s（本来stringは不変のはず）:", s)

	fmt.Println("\n--- 比較対象: 通常の string(b) 変換（コピーが発生し安全） ---")
	b2 := []byte("safe copy")
	s2 := string(b2) // 標準の変換はコピーを作るため、s2 は b2 から独立している
	b2[0] = 'S'
	fmt.Println("b2 を書き換えた後の s2（コピーなので影響を受けない）:", s2)
}

実行結果（実測。go1.26.2 darwin/amd64で確認済み）:

📋 コピー--- ゼロコピー変換: b と s がメモリを共有することの実演 ---
変換直後の s: hello, unsafe
b[0]='H' に書き換えた後の s（本来stringは不変のはず）: Hello, unsafe

--- 比較対象: 通常の string(b) 変換（コピーが発生し安全） ---
b2 を書き換えた後の s2（コピーなので影響を受けない）: safe copy

main_padding.go（(3) 構造体パディングの実測。上のmain.goと同じディレクトリで動かす場合はfuncやtype名の重複に注意し、別ファイル/別mainとして実行すること）

📋 コピーpackage main

import (
	"fmt"
	"unsafe"
)

// BadOrder は bool(1バイト) → int64(8バイト) → bool(1バイト) の順で並べており、
// int64 のアライメント要求（8バイト境界）を満たすために A の後に7バイトの
// パディングが挿入され、さらに構造体全体のサイズも8の倍数に切り上げられる。
type BadOrder struct {
	A bool
	B int64
	C bool
}

// GoodOrder はサイズの大きい型から並べることでパディングを最小化した例。
type GoodOrder struct {
	B int64
	A bool
	C bool
}

func main() {
	var bo BadOrder
	var g GoodOrder

	fmt.Printf("BadOrder:  Sizeof=%d bytes\n", unsafe.Sizeof(bo))
	fmt.Printf("  A offset=%d, B offset=%d, C offset=%d\n",
		unsafe.Offsetof(bo.A), unsafe.Offsetof(bo.B), unsafe.Offsetof(bo.C))

	fmt.Printf("GoodOrder: Sizeof=%d bytes\n", unsafe.Sizeof(g))
	fmt.Printf("  B offset=%d, A offset=%d, C offset=%d\n",
		unsafe.Offsetof(g.B), unsafe.Offsetof(g.A), unsafe.Offsetof(g.C))
}

実行結果（実測・64bitアーキテクチャの場合。32bit環境では数値が変わる）:

📋 コピーBadOrder:  Sizeof=24 bytes
  A offset=0, B offset=8, C offset=16
GoodOrder: Sizeof=16 bytes
  B offset=0, A offset=8, C offset=9

(1)(4)(5) の説明:

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• 高性能なHTTPルータ・パーサー: valyala/fasthttpのようなライブラリは、リクエストのバイト列をコピーせずに文字列として扱うためにunsafeを活用し、アロケーションを削減している
• 標準ライブラリ自身の内部実装: strings.BuilderのString()メソッドや、syscallパッケージのシステムコール呼び出しなど、Go標準ライブラリの内部にもunsafeが使われている箇所がある（公開APIの利用者はその存在を意識せずに安全に使える設計になっている）
• cgoによるC言語とのメモリ共有: CのライブラリにGoのメモリを渡す、またはCが確保したメモリをGo側で読み書きする場合、型を持たない生ポインタとしての受け渡しが必要になる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: GODEBUG=checkptr=1 go run main.go（またはgo test）を実際に実行し、正しい変換パターンではpanicが起きないことを確認してみましょう。さらに、意図的にunsafe.Sliceのlenを元のバッファより大きい値で呼び出し、範囲外アクセスがどのように検出（または検出されないか）を観察すると理解が深まります
• 次回予告: ジェネリクス応用（制約・型セット） — Day 022で学んだジェネリクスの基礎を発展させ、独自の型制約インターフェースを設計する実装問題を扱います

🎯 自己評価

自分の回答

気づき・メモ