No, realloc en la memoria devuelta por posix_memalign ni ISO ni POSIX garantizan que mantenga la misma alineación. Un realloc puede simplemente expanda el bloque actual en la misma dirección, pero también puede mover el bloque a una dirección diferente cuya alineación sea menos estricta que la original.
Si desea la misma alineación, probablemente sea mejor asignar otro bloque y copiar los datos.
Desafortunadamente, no hay posix_memalign_realloc funcionar en la Especificación UNIX Única tampoco.
Si no quiere pasar por la molestia de copiar datos cada tiempo, podrías probar el realloc y, si la alineación de eso no fue la esperada, entonces y solo entonces llama al posix_memalign para obtener una dirección correctamente alineada y copiar los datos allí, liberando la dirección anterior cuando haya terminado.
Esto puede resultar en:
- cero copias (si el bloque actual se puede expandir en el lugar);
- una copia (si
realloccopia pero resulta que le da un bloque correctamente alineado); o - dos copias (si
realloccopias y luego también tiene que copiar debido a la desalineación).
puede también dan como resultado menos copias de las indicadas dependiendo de la implementación de administración de memoria subyacente. Por ejemplo, una "copia" puede implicar simplemente reasignar bloques de memoria en lugar de mover físicamente los datos.
Por lo tanto, es posible que desee mantener algunas estadísticas para ver si este esquema vale la pena.
Solo tenga en cuenta que ni las páginas man de POSIX ni las de Linux especifican si usted puede o no puede pasa estos punteros a realloc , solo que puedes pasarlos a free .
Sin embargo, según el código fuente actual de GNU libc, parece funcionar, aunque eso no garantiza que seguirá funcionando en el futuro :-)
Mi temor era que asignaría la memoria normalmente (alineación estándar) y devolvería una dirección compensada (es decir, no la dirección real asignada, sino una N bytes más allá de eso) que free fue lo suficientemente inteligente como para volver a la dirección real antes de tejer su magia.
Una forma de hacerlo sería almacenar el real dirección inmediatamente antes de la dirección remitida, aunque esto, por supuesto, conduciría a un desperdicio incluso para las asignaciones regulares.
En ese caso, free puede haberse hecho inteligente (ya que las especificaciones dicen que debe ser capaz de manejar las asignaciones realizadas por posix_memalign ) pero realloc es posible que no se le haya dado la misma inteligencia (ya que los documentos guardan silencio al respecto).
Sin embargo, basado en GNU glibc 2.14.1, en realidad asigna más memoria de la necesaria y luego juega con la arena para liberar el espacio previo y posterior, de modo que la dirección devuelta sea una dirección "real", utilizable por free o realloc .
Pero, como se indicó, la documentación no garantiza esto.