いいえ、realloc posix_memalign から返されたメモリについて ISO または POSIX のいずれによっても、同じアライメントを維持することは保証されていません。 realloc かもしれません 単純に現在のブロックを同じアドレスで拡張しますが、ブロックを元のブロックよりアライメントが厳密でない別のアドレスに移動することもあります。
同じ配置が必要な場合は、別のブロックを割り当ててデータをコピーするのがおそらく最善です。
残念ながら posix_memalign_realloc はありません 単一 UNIX 仕様のいずれかで機能します。
毎回データをコピーする手間をかけたくない場合 今度は realloc を試すことができます そして、その位置合わせが期待どおりでなかった場合は、そのときだけ posix_memalign を呼び出す 正しく配置されたアドレスを取得してそこにデータをコピーし、完了したら古いアドレスを解放します。
これにより、以下が発生する可能性があります:
- ゼロ コピー (現在のブロックをその場で展開できる場合);
- 1 部 (
reallocの場合) コピーしますが、たまたま正しく配置されたブロックが得られます);または - 2 部 (
reallocの場合) コピーしてから、ずれのためにコピーする必要があります)。
かもしれません また、基になるメモリ管理の実装によっては、示されているよりもコピーが少なくなります。たとえば、「コピー」には、データを物理的に移動するのではなく、単にメモリ ブロックを再マッピングすることが含まれる場合があります。
したがって、このスキームが価値があるかどうかを確認するために、いくつかの統計を保持することをお勧めします。
POSIX や Linux のマニュアル ページでは、できるかどうかさえ指定されていないことに注意してください。 これらのポインタを realloc に渡します 、 free に渡すことができるだけです .
ただし、現在の GNU libc ソース コードに基づくと、動作しているように見えますが、今後も動作し続けるという保証はありません :-)
私が恐れていたのは、通常どおりにメモリを割り当て (標準アライメント)、オフセット アドレスを返すことでした (つまり、実際に割り当てられたアドレスではなく、1 つの N)。 それ以上のバイト) which free 魔法を織り込む前に実際のアドレスに戻るほどの知性を持っていた.
その方法の 1 つは、実際の 返されたアドレスの直前のアドレスはもちろん、これは通常の割り当てでも浪費につながります.
その場合、free インテリジェント化されている可能性があります（仕様では、posix_memalign によって行われた割り当てを処理できなければならないと言われているため） ) でも realloc 同じ知性が与えられていない可能性があります (ドキュメントはその件について沈黙しているため)。
ただし、GNU glibc 2.14.1 に基づいて、実際には必要以上のメモリを割り当ててから、アリーナをいじって前後のスペースを解放し、返されるアドレスが「実際の」アドレスになり、free または realloc .
ただし、前述のとおり、ドキュメントはこれを保証していません。