Cの文字配列があるとしchar buf[15]ます。たとえば、変数のint set_me = 0直後のメモリ位置にデータが保存されているとしますchar buf[15]。bufstring "aaabbbcccdddeee\xef\xbe\xad\xde"でオーバーフローした場合、set_meデータ型は整数から文字配列に変更されますか？
回答:
番号。
変数の「データ型」は、ソースコードにのみ関連します（一部の言語にのみ関連します）。変数の処理方法をコンパイラーに指示します。
これらの高レベルのデータ型は、コンパイルされた（ネイティブ）コードには存在しません。コンパイラが生成する命令に影響を与える可能性がありますが、命令自体は、データが文字または数値を表すかどうかは関係ありません。
変数はハードウェアには存在しません。ハードウェアでは、メモリの場所とそれらを操作する命令があります。
変数は、メモリの場所にあるデータのビューと見なすことができます。同じメモリを少しだけ細かく見れば（同じ場所を参照する異なるタイプの異なる変数）、同じバイナリ値は異なる意味を持つ可能性があります。
たとえば、バイト0x41はUTF-8でエンコードされた文字として解釈されますA。また、1バイト整数として解釈されることもあります65。また、マルチバイト整数または浮動小数点数の1バイト、またはマルチバイト文字エンコーディングの1バイトとして解釈することもできます。それはビットセットかもしれません0b1000001。同じメモリ位置の同じバイトからすべて。C言語では、これらの異なる型にキャストすることでこの効果を確認できます。
「バッファオーバーフロー」が発生すると、コンパイラや言語が予期する範囲を超えて何かをしていることになります。ただし、ハードウェアに関する限り1、バイト（単一または複数）をメモリの場所に書き込みます。メモリーロケーションには「タイプ」はありません。実際、ハードウェアは、特定のバイトのセットがコード内で配列またはバッファになることさえ知りません。
次にコード内のそのメモリ位置にアクセスするときはいつでも、命令は最初に定義されたとおりに実行されます。例えば、彼らはそこに番号を期待していたならば、彼らはデータのバイト何に作用しているかのよう彼らは数でした。
この例を使用するにintは、符号付きの4バイト（32ビット）整数であると想定します。
+-------------+--------------------------------------------+-----------+
| Source code | char[15] | int |
+-------------+--------------------------------------------------------+
| Memory |61|61|61|62|62|62|63|63|63|64|64|64|65|65|65|EF|BE|AD|DE|
+-------------+--------------------------------------------------------+
ビッグエンディアンシステムを想定すると、intのメモリロケーションにが含まれていることがわかり0xEFBEADDEます2。これは、署名された32ビットint -272716322です。同じメモリをunsigned int（uint）と解釈すると、4022250974代わりに解釈されます。メモリ内のまったく同じデータの場合、意味は完全にデータの表示方法に依存します。
1保護されたメモリ領域への書き込みを妨げるメカニズムがいくつかあり、そうしようとするとプログラムがクラッシュします。
2 x86は実際にはリトルエンディアンです。つまり、大きな値を構成するバイトを逆方向に解釈します。したがって、x86では代わりに0xDEADBEEF、署名付き-559038737または署名なしを指定し3735928559ます。
0xdeadbeef、x86アーキテクチャでは、10進数の対応よりもメモリ内のスペースが少なくなり3735928559ますか？
0xDEADBEEFとしてメモリに記憶されます0x30 0x78 0x44 0x45 0x41 0x44 0x42 0x45 0x45 0x46。
0xEFBEADDE。たぶんそれを少し言い換えます。そうでなければ、これは素晴らしい答えです-私は特に「ビュー」のアナロジーと「目を細める」アイデアが好きです:)