0


ヒープアロケータ(malloc)を実装しています。マジックナンバーを選択して、指定したポインタが割り当てたデータ構造を指しているかどうかを確認する必要があります。マジックナンバーが完全に安全であるとは考えられないことは私には明らかなようですが(番号をチェックすれば、データ構造の1つを確実に指すことができます)、何かを見逃した可能性があります。夢の数を教えてください、本当にありがたいです。事前にThx。

4

4 に答える 4

1

それはあなたがこれを何のためにやっているかによります。my_mallocプログラミングの間違いを見つけようとする場合(たとえば、誤って/my_freemalloc/を混同しないようにしたい場合free)、ランダムな値を選択します。もちろん、そのようなケースを検出できない場合もありますが、それは実際には問題ではありません。それは決して起こらないはずです。だから、ここで:

#define MAGIC_32BIT 0x77A5844CU
#define MAGIC_64BIT 0xD221A6BE96E04673UL

正しさがこれに依存している場合、あなたは本当にこれを別の方法で行うべきです。たとえば、ハッシュやツリー、または特別な場合にはビットマップで割り当てたアドレスを追跡します。

実際にmalloc/freeを実装している場合(たとえば、独自のCライブラリを作成している場合)、編集freeされていないものmalloc(NULLを除く)の実行は標準では未定義の動作であるため、コードで実行する必要はありません。何が起こるか心配してください。

于 2011-02-15T19:15:21.933 に答える
0

私はそのようなことをしていません(私はヒープを操作しましたが、アロケータを実装しませんでした)、あなたが何をしようとしているのかわかりませんが、おそらくこれはハッシュを使用する必要がある場合です。

正確に何をしているかに応じて、メモリチャンクのアドレス、またはそれに含まれるデータをハッシュすることを意味します(そして、何かを変更するたびに、これはハッシュを再計算することを意味します)、またはメモリ操作のある種のIDを意味します。

繰り返しますが、私はあなたが何を達成しようとしているのかわかりません、そしてそれらは私の2セントです。

于 2011-02-15T18:56:26.063 に答える
0

TALLOC_MAGIC 0xe814ec70

これは、ここtalloc.cのソースコードのファイルからのものです。もちろん、tallocがこのマジックナンバーを選んだ理由を調べる必要がありますが、それは始まりです。

于 2011-02-15T19:07:28.383 に答える
0

単一のマジックナンバーを選択するのではなく、乱数(できれば、下位8ビットのセットの少なくとも1つを使用して-たとえば、1でORをとることでこれを強制できます)または定数を使用する必要があります-選択してからアドレス(たとえば、チェックしているアドレス)とXOR(^)します。このアプローチにより、偶発的な衝突の可能性が大幅に減少します。

たとえば、オブジェクトヘッダー(または、作成するアロケータの種類によってはページヘッダー)を作成する場合は、を格納しMAGIC ^ addrます。addr有効かどうかを確認したい場合はvalue == addr ^ MAGIC、(もちろん、適切なキャストを使用して)確認してください。

ちなみに、独自のカスタムメモリアロケータの作成に着手する前に、OOPSLA 2002のこのペーパー(Berger、Zorn、McKinleyによるカスタムメモリ割り当ての再検討)をお読みください。

http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

概要: パフォーマンスの向上を望むプログラマーは、多くの場合、カスタムメモリアロケータを使用します。この詳細な調査では、カスタムアロケータを使用する8つのアプリケーションを調べます。驚いたことに、これらのアプリケーションのうち6つについては、最先端の汎用アロケータ(Leaアロケータ)がカスタムアロケータと同等またはそれ以上のパフォーマンスを発揮します。2つの例外は、より高いパフォーマンス(最大44%の改善)を提供するリージョンを使用します。リージョンはまた、プログラマーの負担を軽減し、メモリリークの原因を排除します。ただし、プログラマーがリージョン内の個々のオブジェクトを解放できないと、メモリ消費量が大幅に増加する可能性があることを示します。さらに悪いことに、この制限により、一般的なプログラミングイディオムにリージョンを使用できなくなり、その有用性が低下します。リープと呼ばれる汎用および地域ベースのアロケータの一般化を示します。リープはリージョンとヒープの組み合わせであり、個々のオブジェクトの削除を追加して、リージョンのセマンティクスの全範囲を提供します。リープの実装が高性能を提供し、リージョンのようなセマンティクスで他のアロケータよりも優れていることを示します。次に、ケーススタディを使用して、実際の刈り取りのスペースの利点とソフトウェアエンジニアリングの利点を示します。私たちの結果は、高速リージョンを必要とするプログラマーはリープを使用する必要があり、カスタムアロケーターを検討しているほとんどのプログラマーは代わりにLeaアロケーターを使用する必要があることを示しています。リージョンのようなセマンティクスで他のアロケータよりも優れています。次に、ケーススタディを使用して、実際の刈り取りのスペースの利点とソフトウェアエンジニアリングの利点を示します。私たちの結果は、高速リージョンを必要とするプログラマーはリープを使用する必要があり、カスタムアロケーターを検討しているほとんどのプログラマーは代わりにLeaアロケーターを使用する必要があることを示しています。リージョンのようなセマンティクスで他のアロケータよりも優れています。次に、ケーススタディを使用して、実際の刈り取りのスペースの利点とソフトウェアエンジニアリングの利点を示します。私たちの結果は、高速リージョンを必要とするプログラマーはリープを使用する必要があり、カスタムアロケーターを検討しているほとんどのプログラマーは代わりにLeaアロケーターを使用する必要があることを示しています。

于 2011-02-15T19:34:08.467 に答える