Posso supporre che chiamare realloc con una dimensione più piccola libererà il resto?

Question

Consideriamo questo brevissimo frammento di codice:

#include <stdlib.h> 

int main() 
{ 
    char* a = malloc(20000); 
    char* b = realloc(a, 5); 

    free(b); 
    return 0; 
} 

Dopo aver letto la pagina man di realloc, non ero del tutto sicuro che la seconda riga causerebbe le 19995 byte in più per essere liberati. Per citare la pagina man: The realloc() function changes the size of the memory block pointed to by ptr to size bytes., ma da quella definizione, posso essere sicuro che il resto verrà liberato?

Voglio dire, il blocco puntato da b contiene certamente 5 byte liberi, quindi sarebbe sufficiente per un allocatore pigro che non fa semplicemente nulla per la linea realloc?

Nota: L'allocatore che uso sembra liberare i 19 995 byte in più, come dimostrato da valgrind quando commentando la linea free(b):

==4457== HEAP SUMMARY: 
==4457==  in use at exit: 5 bytes in 1 blocks 
==4457== total heap usage: 2 allocs, 1 frees, 20,005 bytes allocated 

Answer 1

Sì, garantito dallo standard C se è possibile assegnare il nuovo oggetto.

(C99, 7.20.3.4p2) "La funzione realloc rilascia il vecchio oggetto puntato da ptr e restituisce un puntatore a un nuovo oggetto con le dimensioni specificate per dimensione."

Answer 2

Sì — se riesce.

tuo frammento di codice mostra un noto, nefasto errore:

char* b = (char*) realloc(a, 5); 

In caso positivo, la memoria precedentemente allocato a a verrà liberata, e b punterà 5 byte di memoria che possono o non può sovrapporsi al blocco originale.

Tuttavia, se la chiamata non riesce, b sarà null, ma a sarà ancora puntare alla sua memoria originale, che sarà ancora valido. In tal caso, è necessario free(a) per rilasciare la memoria.

E 'ancora peggio se si utilizza il comune (pericoloso) idioma:

a = realloc(a, NEW_SIZE);  // Don't do this! 

Se la chiamata a realloc non riesce, una sarà null e la sua memoria originale saranno orfani, che lo rendono irrimediabilmente perduto fino a quando il programma di uscite.

Answer 3

Questo dipende dall'implementazione della libc. Tutti i seguenti è un comportamento conforme:

• non fare nulla, cioè lasciando che i dati rimangono dove si trova e la restituzione del vecchio blocco, forse ri-utilizzando i byte ora non utilizzate per ulteriori accantonamenti (afaik tale riutilizzo è non comune)
• copiare i dati su un nuovo blocco e rilasciando il vecchio indietro al sistema operativo
• copiare i dati su un nuovo blocco e la conservazione del vecchio per ulteriori assegnazioni

e 'anche possibile a

• ritorno un puntatore nullo se un nuovo blocco non può essere allocato

In questo caso, i vecchi dati saranno inoltre rimangono dove è, che può portare a perdite di memoria, ad esempio se il ritorno il valore di realloc() sovrascrive l'unica copia del puntatore su quel blocco.

Un'implementazione ragionevole della libc utilizzerà un po 'di euristica per determinare quale soluzione sia la più efficiente.

Ricorda inoltre che questa descrizione è a livello di implementazione: semanticamente, realloc() libera sempre l'oggetto finché l'allocazione non fallisce.

Answer 4

Sembra improbabile che 19995 byte siano stati liberati. Ciò che è più probabile è che realloc ha sostituito il blocco da 20000 byte con un altro blocco da 5 byte, , ovvero il blocco da 20000 byte è stato liberato e un nuovo blocco da 5 byte è stato allocato.

Answer 5

La funzione realloc ha il seguente contratto:

void * result = realloc (PTR, new_size)

• Se il risultato è NULL, allora PTR è ancora valida e immutata.
• Se il risultato è diverso da NULL, quindi ptr non è più valido (come se fosse stato liberato) e non deve essere mai più utilizzato. risultato è ora un puntatore a esattamente new_size byte di dati.

I precisi dettagli di ciò che accade sotto il cofano sono specifiche per l'attuazione - per un risultato ad esempio può essere uguale PTR (ma lo spazio aggiuntivo oltre new_size non deve essere toccato più) e realloc può chiamare gratis, oppure può fare la sua libera rappresentazione interna. La cosa fondamentale è che come sviluppatore non si ha più la responsabilità di ptr se realloc restituisce un valore non nullo e se ne ha ancora la responsabilità se realloc restituisce NULL.