malloc / libre. puede leer de la memoria liberada

Aquí cómo me recuerdo malloc

char *convertToPostfix(char **infixExpr) { char *postfixExpr = (char *) malloc(strlen(*infixExpr) * sizeof(char) * 2); ... return postfixExpr; } 

Aquí cómo uso esta memoria:

 char *subexpr = convertToPostfix(infixExpr); free(subexpr); while (*subexpr) postfixExpr[i++]=*subexpr++; 

¿Por qué este progtwig funciona normalmente después de free(subexpr); Quiero decir, ¿por qué es posible iterar mientras se libera?

¿Y estoy haciendo todo bien trabajando de tal manera, cuando la función devuelve algo de memoria, que se libera en otro contexto?

Su progtwig exhibe un comportamiento indefinido. En resumen, cualquier cosa puede suceder, incluso si su progtwig parece funcionar.

Es bastante común que las implementaciones de malloc / free no devuelvan los bloques de memoria al sistema operativo subyacente inmediatamente después de realizar la llamada free . Esto se hace por razones de rendimiento. La próxima llamada a malloc puede ser manejada más eficientemente devolviendo un puntero al bloque que acaba de liberar y, por lo tanto, reutilizándolo. En este punto, en su código, habría dos punteros que se refieren al mismo bloque de memoria y quién sabe qué pasará después.

¡NO LO USES! Debido a que los progtwigdores confiaban en algún comportamiento declarado como no definido, otros progtwigdores deberían reproducir otros errores más adelante.

http://www.joelonsoftware.com/articles/fog0000000054.html

Windows 95? No hay problema. Agradable nueva API de 32 bits, pero aún funcionaba perfectamente con el viejo software de 16 bits. Microsoft se obsesionó con esto, y pasó una gran parte del cambio probando todos los progtwigs antiguos que pudieron encontrar con Windows 95. Jon Ross, quien escribió la versión original de SimCity para Windows 3.x, me dijo que accidentalmente dejó un error en SimCity donde leyó la memoria que acababa de liberar. Sí. Funcionó bien en Windows 3.x, porque la memoria nunca fue a ninguna parte. Aquí está la parte sorprendente: en las versiones beta de Windows 95, SimCity no estaba funcionando en las pruebas. Microsoft rastreó el error y agregó un código específico a Windows 95 que busca SimCity. Si encuentra SimCity en ejecución, ejecuta el asignador de memoria en un modo especial que no libera memoria de inmediato. Ese es el tipo de obsesión con la compatibilidad con versiones anteriores que hizo que las personas estuvieran dispuestas a actualizar a Windows 95.

La lectura / escritura de / a la memoria que se ha liberado es un comportamiento indefinido. Tu progtwig puede funcionar hoy, y bloquearse mañana; o esperar hasta la próxima luna llena antes de estrellarse.

La razón por la que parece funcionar es porque el administrador del montón todavía no ha asignado esa memoria a otra persona que llama malloc() . Y free() no modificó el contenido existente de la memoria, por lo que cualquier cosa que haya escrito en esas ubicaciones antes de la llamada a free() todavía está allí. Pero confiar en este comportamiento es una receta para el desastre.

Este es un comportamiento indefinido. Parece funcionar, pero en realidad cualquier cosa puede pasar.

La razón por la que parece funcionar (probablemente) es que la memoria no se borra cuando usted llama free , sino que está marcada como reutilizable por el sistema operativo.

Eso es claramente un comportamiento indefinido.

Liberar memoria no significa ponerla en cero. La mayoría de las veces, la memoria simplemente se marcará como “disponible”. Cuando lo usas justo después de liberarlo, permanece intacto. Pero si por alguna razón se necesita más memoria, es probable que se sobrescriba.