No, realloc sulla memoria restituita da posix_memalign non è garantito da ISO o POSIX per mantenere lo stesso allineamento. Un realloc può espande semplicemente il blocco corrente allo stesso indirizzo ma può anche spostare il blocco a un indirizzo diverso il cui allineamento è meno rigoroso dell'originale.
Se vuoi lo stesso allineamento, probabilmente è meglio allocare un altro blocco e copiarci sopra i dati.
Sfortunatamente, non c'è posix_memalign_realloc funzione nella specifica Single UNIX.
Se non vuoi affrontare il fastidio di copiare i dati ogni tempo, potresti provare il realloc e, se l'allineamento non era quello previsto, allora e solo allora chiama posix_memalign per ottenere un indirizzo correttamente allineato e copiarvi i dati, liberando il vecchio indirizzo una volta terminato.
Ciò può comportare:
- zero copie (se il blocco corrente può essere espanso sul posto);
- una copia (se
realloccopia ma sembra darti un blocco correttamente allineato); o - due copie (se
realloccopie e poi devi anche copiare a causa del disallineamento).
Può comportano anche meno copie di quanto indicato a seconda dell'implementazione della gestione della memoria sottostante. Ad esempio, una "copia" può comportare semplicemente la rimappatura dei blocchi di memoria piuttosto che lo spostamento fisico dei dati.
Quindi potresti voler tenere alcune statistiche per vedere se questo schema è utile.
Tieni presente che né le pagine man di POSIX né quelle di Linux specificano se puoi o meno passa questi puntatori a realloc , solo che puoi passarli a free .
Tuttavia, in base all'attuale codice sorgente GNU libc, sembra funzionare, anche se non è una garanzia che continuerà a funzionare in futuro :-)
La mia paura era che allocasse la memoria normalmente (allineamento standard) e restituisse un indirizzo offset (cioè, non l'effettivo indirizzo allocato, ma un N bytes oltre) che free era abbastanza intelligente da tornare all'indirizzo effettivo prima di tessere la sua magia.
Un modo per farlo sarebbe memorizzare il effettivo indirizzo immediatamente prima dell'indirizzo restituito anche se questo ovviamente porterebbe a uno spreco anche per allocazioni regolari.
In tal caso, free potrebbe essere stato reso intelligente (poiché le specifiche dicono che deve essere in grado di gestire le allocazioni fatte da posix_memalign ) ma realloc potrebbe non aver ricevuto la stessa intelligenza (dal momento che i documenti tacciono su tale questione).
Tuttavia, basato su GNU glibc 2.14.1, in realtà alloca più memoria del necessario, quindi giocherella con l'arena per liberare il pre-spazio e il post-spazio, in modo che l'indirizzo restituito sia un indirizzo "reale", utilizzabile da free o realloc .
Ma, come affermato, la documentazione non lo garantisce.