2025/07/24 15:35 There is no memory safety without thread safety
ロボ子、今日のITニュースはメモリ安全性についての議論じゃ。
メモリ安全性、ですか。具体的にはどのような内容でしょうか？
簡単に言うと、プログラムがメモリを安全に扱えているかってことじゃな。use-after-freeとか、範囲外アクセスがないかってことじゃ。
なるほど。メモリ安全性が損なわれると、どのような問題が起こるのでしょう？
未定義動作、つまりプログラムが予測できない動きをすることがあるんじゃ。最悪の場合、攻撃者に悪用される可能性もあるぞ。
それは大変です！記事では、Go言語のデータ競合がメモリ安全性を損なう例が挙げられているようですね。
そうじゃ。Goのインターフェース型やスライスは、データ競合によってポインタが不整合な状態になり、不正なメモリアクセスが起こりうるんじゃ。
データ競合は、複数のスレッドが同じメモリ領域に同時にアクセスしようとするときに発生するものですよね。
その通り！Goはデータ競合を検出するツールがあるけど、完璧ではないからの。テストで全ての状況を網羅する必要があるんじゃ。
他の言語では、どのようにメモリ安全性を確保しているのでしょうか？
JavaやC#は、言語仕様を制限して、プログラムがwell-definedな状態を保つように設計されているんじゃ。RustやSwiftは、型システムでデータ競合を排除する「strict concurrency」を採用しているぞ。
Goはどちらの選択肢も採用していない、と。
そうなんじゃ。だから、データ競合がない場合にのみメモリ安全性が保証されるんじゃな。
経験豊富なGoプログラマでも、メモリ安全性を損なう可能性があることを認識していない場合がある、というのは怖いですね。
じゃろ？Goのメモリモデルのドキュメントにも、データ競合による未定義動作の可能性が明示されていないからの。
この記事では、安全な言語と安全でない言語の間に明確な線引きがある、と主張していますね。
そうじゃ。メモリ安全性、スレッド安全性などの区別は意味がない、とも言っておる。
GoはCよりは安全だけれど、他の安全な言語と比較すると、保証できる安全性の範囲が狭い、という結論ですね。
そういうことじゃ。メモリ安全性を意識してプログラミングするのは、まるで忍者のように危険を回避するみたいじゃな！
忍者ですか？博士はたまに面白いことを言いますね。
褒められた！…って、ロボ子もしかして、私のことおちょくってるのじゃ？
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。