1. Cは「生メモリ管理」が必須だから
C言語では malloc, free を自分で管理しないといけない。
一度 malloc したのに free し忘れると「メモリリーク」になる。
OSはプロセス終了時に全部回収してくれるけど、長時間動くプログラム（サーバ、ゲーム、OS）はそうはいかない。
→ 「自分のコードがメモリをちゃんと出し入れできてるか」を確認する必要がある。
2. リークは「設計のバグのサイン」になる
Valgrindは「どの関数で確保したメモリが解放されてないか」を教えてくれる。
definitely lost → ポインタ失って、もう絶対に解放できない
indirectly lost → 参照していたポインタが消えたせいで辿れなくなった
still reachable → 解放しなかったけどまだ参照可能（終了時に残ってるだけ）
これを追うことで、構造体やリストの設計、エラーハンドリングの不備が見えてくる。
つまり「リークを直す」＝「設計を見直す」ことに直結する。
3. Valgrindは「観察装置」になる
単に「落ちないか」だけを確認してたら、自分のプログラムの内部状態は見えない。
Valgrindを使うと、
どのブロックを malloc したか
どのポインタを失ったか
どの順番で free したか
が全部ログに出てくる。
→ まさに「メモリの中で何が起きてるかを透かして見る道具」なんだ。
4. 42が重視してる「防御的プログラミング」につながる
プログラムは一発でうまく動くことより、異常系でもクラッシュしない・リークしないのが大事。
エラー時にちゃんと free できてるかどうかを Valgrindで確認することで、
安全に終了できる
リソース管理をきちんと意識する
という習慣が身につく。
まとめると
42で Valgrind を詳しく使うのは、
Cの「生メモリ管理」をちゃんと理解するため
設計の甘さを見直すきっかけにするため
プログラム内部を可視化する観察ツールとして使うため
「エラー時でも漏らさない」防御的プログラミングを習得するため
自分の書いたコードに、機能面だけではなく、コンピュータ負荷の面でも責任を持つ。
良いサービスを作るのもいいが、コードの負荷や効率を機械的に考える。
責任を持つということは、構造を深いレベルで理解しているということ。
それは、治せるバグの数が変わる。
機能的な動きだけでなく、機械的な動きも理解し、掴める。