Non, realloc sur la mémoire renvoyée par posix_memalign n'est pas garanti par ISO ou POSIX pour maintenir le même alignement. Un realloc peut développez simplement le bloc actuel à la même adresse, mais cela peut également déplacer le bloc vers une adresse différente dont l'alignement est moins strict que l'original.
Si vous voulez le même alignement, il est probablement préférable d'allouer un autre bloc et de copier les données.
Il n'y a malheureusement pas de posix_memalign_realloc fonction dans la spécification UNIX unique.
Si vous ne voulez pas avoir à copier des données chaque fois, vous pouvez essayer le realloc et, si l'alignement de cela n'était pas comme prévu, alors et seulement alors appeler le posix_memalign pour obtenir une adresse correctement alignée et y copier les données, en libérant l'ancienne adresse une fois terminé.
Cela peut entraîner :
- zéro copie (si le bloc actuel peut être étendu sur place) ;
- un exemplaire (si
realloccopies mais il se trouve qu'il vous donne un bloc correctement aligné) ; ou - deux exemplaires (si
realloccopies et vous devez également copier en raison d'un mauvais alignement).
Il peut entraînent également moins de copies qu'indiqué en fonction de l'implémentation sous-jacente de la gestion de la mémoire. Par exemple, une "copie" peut simplement impliquer le remappage des blocs de mémoire plutôt que le déplacement physique des données.
Vous voudrez peut-être conserver des statistiques pour voir si ce régime en vaut la peine.
Gardez simplement à l'esprit que ni les pages de manuel POSIX ni Linux ne précisent si vous pouvez ou non pouvoir passez ces pointeurs à realloc , seulement que vous pouvez les transmettre à free .
Cependant, sur la base du code source actuel de la GNU libc, cela semble fonctionner, bien que cela ne garantisse pas qu'il continuera à fonctionner à l'avenir :-)
Ma crainte était qu'il alloue de la mémoire normalement (alignement standard) et renvoie une adresse de décalage (c'est-à-dire, pas l'adresse réelle allouée, mais un N octets au-delà) dont free était assez intelligent pour redevenir l'adresse réelle avant de tisser sa magie.
Une façon de faire serait de stocker le réel adresse immédiatement avant l'adresse renvoyée, bien que cela entraînerait bien sûr un gaspillage, même pour les allocations régulières.
Dans ce cas, free peut avoir été rendu intelligent (puisque les spécifications indiquent qu'il doit être capable de gérer les allocations effectuées par posix_memalign ) mais realloc n'ont peut-être pas reçu les mêmes renseignements (puisque les documents sont muets à ce sujet).
Cependant, basé sur GNU glibc 2.14.1, il alloue en fait plus de mémoire que nécessaire, puis joue avec l'arène pour libérer le pré-espace et le post-espace, de sorte que l'adresse renvoyée est une "vraie" adresse, utilisable par free ou realloc .
Mais, comme indiqué, la documentation ne le garantit pas.