È possibile accedere alla memoria di una variabile locale al di fuori del suo ambito?

Ho il codice seguente.

#include <iostream>

int * foo()
{
    int a = 5;
    return &a;
}

int main()
{
    int* p = foo();
    std::cout << *p;
    *p = 8;
    std::cout << *p;
}

E il codice è in esecuzione senza eccezioni di runtime!

L'output è stato 58

Come può essere? La memoria di una variabile locale non è inaccessibile al di fuori della sua funzione?

Come può essere? La memoria di una variabile locale non è inaccessibile al di fuori della sua funzione?

Si affitta una stanza d'albergo. Metti un libro nel primo cassetto del comodino e vai a dormire. Fai il check out la mattina dopo, ma "dimentica" di restituire la chiave. Hai rubato la chiave!

Una settimana dopo, ritorni in hotel, non fare il check-in, sgattaiolare nella tua vecchia stanza con la chiave rubata e guardare nel cassetto. Il tuo libro è ancora lì. Stupefacente!

Come può essere? Il contenuto del cassetto di una stanza d'albergo non è inaccessibile se non l'hai affittata?

Bene, ovviamente quello scenario può accadere nel mondo reale senza problemi. Non esiste una forza misteriosa che fa scomparire il tuo libro quando non sei più autorizzato a trovarti nella stanza. Né esiste una forza misteriosa che ti impedisce di entrare in una stanza con una chiave rubata.

La direzione dell'hotel non è tenuta a rimuovere il tuo libro. Non hai stipulato un contratto con loro che dice che se lasci qualcosa alle loro spalle, te lo distruggeranno. Se rientri illegalmente nella tua camera con una chiave rubata per riaverla, il personale di sicurezza dell'hotel non è tenuto a sorprenderti di nascosto. Non hai stipulato un contratto con loro che dice "se provo a intrufolarmi di nuovo nel mio stanza più tardi, devi fermarmi. " Piuttosto, hai firmato un contratto con loro che diceva "Prometto di non rientrare più tardi nella mia stanza", un contratto che hai rotto .

In questa situazione può succedere di tutto . Il libro può essere lì - sei stato fortunato. Il libro di qualcun altro può essere lì e il tuo potrebbe essere nella fornace dell'hotel. Qualcuno potrebbe essere lì quando entri, facendo a pezzi il tuo libro. L'hotel avrebbe potuto rimuovere completamente il tavolo e prenotare e sostituirlo con un armadio. L'intero hotel potrebbe essere quasi distrutto e sostituito con uno stadio di calcio, e morirai in un'esplosione mentre ti stai avvicinando di soppiatto.

Non sai cosa succederà; quando hai fatto il check out dall'hotel e hai rubato una chiave da utilizzare illegalmente in seguito, hai rinunciato al diritto di vivere in un mondo prevedibile e sicuro perché hai scelto di infrangere le regole del sistema.

C ++ non è un linguaggio sicuro . Ti permetterà allegramente di infrangere le regole del sistema. Se provi a fare qualcosa di illegale e sciocco come tornare in una stanza in cui non sei autorizzato a entrare e frugare in una scrivania che potrebbe anche non esserci più, C ++ non ti fermerà. Linguaggi più sicuri del C ++ risolvono questo problema limitando il tuo potere, ad esempio con un controllo molto più rigoroso sui tasti.

AGGIORNARE

Santo cielo, questa risposta sta suscitando molta attenzione. (Non sono sicuro del perché - l'ho considerato solo una piccola "analogia" divertente, ma qualunque cosa.)

Ho pensato che potrebbe essere germano aggiornarlo un po 'con qualche pensiero tecnico in più.

I compilatori si occupano della generazione di codice che gestisce la memorizzazione dei dati manipolati da quel programma. Esistono molti modi diversi di generare codice per gestire la memoria, ma nel tempo si sono radicate due tecniche di base.

Il primo è avere una sorta di area di memoria "longevo" in cui la "durata" di ciascun byte nella memoria - ovvero il periodo di tempo in cui è validamente associato ad una variabile di programma - non può essere facilmente prevista in anticipo di tempo. Il compilatore genera chiamate in un "gestore di heap" che sa come allocare dinamicamente lo spazio di archiviazione quando è necessario e recuperarlo quando non è più necessario.

Il secondo metodo consiste nell'avere un'area di archiviazione "di breve durata" in cui è nota la durata di ciascun byte. Qui, le vite seguono uno schema di "nidificazione". La più lunga durata di queste variabili di breve durata verrà allocata prima di qualsiasi altra variabile di breve durata e verrà liberata per ultima. Le variabili a vita più breve verranno allocate dopo quelle a vita più lunga e verranno liberate prima di esse. La durata di queste variabili di breve durata è "nidificata" all'interno di quelle di più lunga durata.

Le variabili locali seguono quest'ultimo schema; quando viene inserito un metodo, le sue variabili locali prendono vita. Quando quel metodo chiama un altro metodo, le variabili locali del nuovo metodo prendono vita. Saranno morti prima che le variabili locali del primo metodo siano morte. L'ordine relativo degli inizi e dei finali delle vite degli archivi associati alle variabili locali può essere elaborato in anticipo.

Per questo motivo, le variabili locali vengono generalmente generate come memoria su una struttura di dati "stack", poiché uno stack ha la proprietà che la prima cosa che viene spinta su di essa sarà l'ultima cosa spuntata.

È come se l'hotel decidesse di affittare solo le camere in sequenza, e non è possibile effettuare il check-out fino a quando tutti con un numero di camera superiore a quello che si è verificato.

Quindi pensiamo allo stack. In molti sistemi operativi si ottiene uno stack per thread e lo stack viene assegnato a una determinata dimensione fissa. Quando chiami un metodo, le cose vengono inserite nello stack. Se poi passi un puntatore allo stack fuori dal tuo metodo, come fa il poster originale qui, è solo un puntatore al centro di un blocco di memoria da un milione di byte completamente valido. Nella nostra analogia, fai il check out dall'hotel; quando lo fai, sei appena uscito dalla stanza occupata con il numero più alto. Se nessun altro effettua il check-in dopo di te e torni nella tua camera illegalmente, tutte le tue cose sono garantite per essere ancora lì in questo particolare hotel .

Usiamo stack per negozi temporanei perché sono davvero economici e facili. Non è richiesta un'implementazione di C ++ per utilizzare uno stack per l'archiviazione dei locali; potrebbe usare l'heap. Non lo fa, perché ciò renderebbe il programma più lento.

Non è necessaria un'implementazione di C ++ per lasciare intatta la spazzatura che hai lasciato nello stack in modo da poter tornare in seguito in modo illegale; è perfettamente legale per il compilatore generare codice che ritorni a zero tutto nella "stanza" che hai appena lasciato libero. Non perché, di nuovo, sarebbe costoso.

Non è necessaria un'implementazione di C ++ per garantire che quando lo stack si restringe logicamente, gli indirizzi che erano validi erano ancora mappati in memoria. L'implementazione può dire al sistema operativo "abbiamo finito di usare questa pagina di stack ora. Fino a quando non dico diversamente, emettere un'eccezione che distrugge il processo se qualcuno tocca la pagina di stack precedentemente valida". Ancora una volta, le implementazioni non lo fanno perché è lenta e non necessaria.

Invece, le implementazioni ti consentono di fare errori e cavartela. La maggior parte delle volte. Fino a quando un giorno qualcosa di veramente terribile va storto e il processo esplode.

Questo è problematico. Ci sono molte regole ed è molto facile infrangerle accidentalmente. Ho sicuramente molte volte. E peggio ancora, il problema si presenta spesso solo quando la memoria viene rilevata come miliardi di nanosecondi corrotti dopo che si è verificata la corruzione, quando è molto difficile capire chi l'ha incasinata.

Linguaggi più sicuri per la memoria risolvono questo problema limitando la tua potenza. In C # "normale" semplicemente non c'è modo di prendere l'indirizzo di un locale e restituirlo o conservarlo per dopo. Puoi prendere l'indirizzo di un locale, ma la lingua è progettata in modo intelligente in modo che sia impossibile usarlo dopo la fine del ciclo di vita locale. Per prendere l'indirizzo di un locale e passarlo indietro, devi mettere il compilatore in una modalità speciale "non sicura", e mettere la parola "non sicuro" nel tuo programma, per richiamare l'attenzione sul fatto che probabilmente stai facendo qualcosa di pericoloso che potrebbe infrangere le regole.

Per ulteriori letture:

• Cosa succederebbe se C # consentisse la restituzione di riferimenti? Per coincidenza, questo è l'argomento del post sul blog di oggi:

  https://ericlippert.com/2011/06/23/ref-returns-and-ref-locals/

• Perché utilizziamo stack per gestire la memoria? I tipi di valore in C # sono sempre memorizzati nello stack? Come funziona la memoria virtuale? E molti altri argomenti su come funziona il gestore della memoria C #. Molti di questi articoli sono anche germani per i programmatori C ++:

  https://ericlippert.com/tag/memory-management/

Quello che stai facendo qui è semplicemente leggere e scrivere in memoria che era l'indirizzo di a. Ora che sei fuori da foo, è solo un puntatore a qualche area di memoria casuale. Accade semplicemente che nel tuo esempio quell'area di memoria esista e nient'altro la sta usando al momento. Non rompi nulla continuando a usarlo e nient'altro lo ha ancora sovrascritto. Pertanto, il 5è ancora lì. In un vero programma, quella memoria verrebbe riutilizzata quasi immediatamente e si romperà qualcosa facendo questo (anche se i sintomi potrebbero non apparire fino a molto tempo dopo!)

Quando torni da foo, dici al sistema operativo che non stai più usando quella memoria e può essere riassegnato a qualcos'altro. Se sei fortunato e non viene mai riassegnato, e il sistema operativo non ti sorprende a usarlo di nuovo, allora ti allontanerai dalla bugia. È probabile che finirai per scrivere su qualsiasi altra cosa finisca con quell'indirizzo.

Ora, se ti stai chiedendo perché il compilatore non si lamenta, è probabilmente perché è foostato eliminato dall'ottimizzazione. Di solito ti avvertirà di questo genere di cose. C presume che tu sappia cosa stai facendo, e tecnicamente non hai violato l'ambito qui (non c'è alcun riferimento a ase stesso al di fuori di foo), solo regole di accesso alla memoria, che innesca solo un avviso piuttosto che un errore.

In breve: di solito non funzionerà, ma a volte per caso.

Perché lo spazio di archiviazione non è stato ancora calpestato. Non contare su quel comportamento.

Una piccola aggiunta a tutte le risposte:

se fai qualcosa del genere:

#include<stdio.h>
#include <stdlib.h>
int * foo(){
    int a = 5;
    return &a;
}
void boo(){
    int a = 7;

}
int main(){
    int * p = foo();
    boo();
    printf("%d\n",*p);
}

l'uscita probabilmente sarà: 7

Questo perché dopo il ritorno da foo () lo stack viene liberato e quindi riutilizzato da boo (). Se rimuovi il file eseguibile, lo vedrai chiaramente.

In C ++, puoi accedere a qualsiasi indirizzo, ma ciò non significa che dovresti . L'indirizzo a cui accedi non è più valido. Esso funziona perché nient'altro strapazzate la memoria dopo foo restituito, ma potrebbe bloccarsi in molte circostanze. Prova ad analizzare il tuo programma con Valgrind o anche solo a compilarlo ottimizzato e vedi ...

Non si genera mai un'eccezione C ++ accedendo alla memoria non valida. Stai solo dando un esempio dell'idea generale di fare riferimento a una posizione di memoria arbitraria. Potrei fare lo stesso in questo modo:

unsigned int q = 123456;

*(double*)(q) = 1.2;

Qui sto semplicemente trattando 123456 come l'indirizzo di un doppio e scrivo ad esso. Potrebbe succedere un numero qualsiasi di cose:

1. qpotrebbe in effetti essere veramente un indirizzo valido di un doppio, ad es double p; q = &p;.
2. q potrebbe puntare da qualche parte nella memoria allocata e ho appena sovrascritto 8 byte lì dentro.
3. q punti all'esterno della memoria allocata e il gestore della memoria del sistema operativo invia un segnale di errore di segmentazione al mio programma, causando il termine del runtime.
4. Vinci la lotteria.

Il modo in cui lo configuri è un po 'più ragionevole che l'indirizzo restituito punti in un'area di memoria valida, poiché probabilmente sarà solo un po' più in basso nello stack, ma è ancora una posizione non valida a cui non puoi accedere in un moda deterministica.

Nessuno verificherà automaticamente la validità semantica degli indirizzi di memoria come quella per te durante la normale esecuzione del programma. Tuttavia, un debugger di memoria come lo valgrindfarà felicemente, quindi dovresti eseguire il programma attraverso di esso e testimoniare gli errori.

Hai compilato il tuo programma con l'ottimizzatore abilitato? Ilfoo() funzione è abbastanza semplice e potrebbe essere stata incorporata o sostituita nel codice risultante.

Ma concordo con Mark B sul fatto che il comportamento risultante non è definito.

Il tuo problema non ha nulla a che fare con l' ambito . Nel codice che mostri, la funzione mainnon vede i nomi nella funzione foo, quindi non puoi accedervi adirettamente con questo nome all'esterno foo.

Il problema riscontrato è il motivo per cui il programma non segnala un errore quando si fa riferimento alla memoria illegale. Questo perché gli standard C ++ non specificano un confine molto chiaro tra memoria illegale e memoria legale. Fare riferimento a qualcosa nello stack spuntato a volte causa errori e talvolta no. Dipende. Non contare su questo comportamento. Supponiamo che causerà sempre errori durante la programmazione, ma supponiamo che non segnalerà mai errori durante il debug.

Stai solo restituendo un indirizzo di memoria, è consentito ma probabilmente è un errore.

Sì, se provi a dereferenziare quell'indirizzo di memoria avrai un comportamento indefinito.

int * ref () {

 int tmp = 100;
 return &tmp;
}

int main () {

 int * a = ref();
 //Up until this point there is defined results
 //You can even print the address returned
 // but yes probably a bug

 cout << *a << endl;//Undefined results
}

È un classico comportamento indefinito che è stato discusso qui non due giorni fa: cerca un po 'nel sito. In poche parole, sei stato fortunato, ma sarebbe potuto succedere di tutto e il tuo codice sta rendendo non valido l'accesso alla memoria.

Questo comportamento è indefinito, come ha sottolineato Alex - in effetti, la maggior parte dei compilatori avvertirà di non farlo, perché è un modo semplice per ottenere crash.

Per un esempio del tipo di comportamento spettrale si rischia di ottenere, provare questo esempio:

int *a()
{
   int x = 5;
   return &x;
}

void b( int *c )
{
   int y = 29;
   *c = 123;
   cout << "y=" << y << endl;
}

int main()
{
   b( a() );
   return 0;
}

Questo stampa "y = 123", ma i risultati possono variare (davvero!). Il puntatore sta bloccando altre variabili locali non correlate.

Prestare attenzione a tutti gli avvisi. Non solo risolvere errori.
GCC mostra questo avviso

avviso: indirizzo della variabile locale 'a' restituito

Questa è la potenza di C ++. Dovresti preoccuparti della memoria. Con il -Werrorflag, questo avviso diventa un errore e ora devi eseguirne il debug.

Funziona perché lo stack non è stato modificato (ancora) da quando è stato inserito uno. Chiama alcune altre funzioni (che chiamano anche altre funzioni) prima di accedere di anuovo e probabilmente non sarai più così fortunato ... ;-)

In realtà hai invocato un comportamento indefinito.

Restituzione dell'indirizzo di un'opera temporanea, ma man mano che i temporali vengono distrutti al termine di una funzione, i risultati dell'accesso ad essi non saranno definiti.

Quindi non hai modificato, ama piuttosto la posizione della memoria in cui auna volta era. Questa differenza è molto simile alla differenza tra crash e non crash.

Nelle tipiche implementazioni del compilatore, puoi pensare al codice come "stampa il valore del blocco di memoria con l'indirizzo che era occupato da un". Inoltre, se si aggiunge una nuova chiamata di funzione a una funzione che contiene un locale, intè probabile che il valore di a(o l'indirizzo di memoria autilizzato per indicare) cambi. Ciò accade perché lo stack verrà sovrascritto con un nuovo frame contenente dati diversi.

Tuttavia, questo è un comportamento indefinito e non dovresti fare affidamento su di esso per funzionare!

Può, perché aè una variabile allocata temporaneamente per la durata del suo ambito ( foofunzione). Dopo il ritorno dalla foomemoria è gratuito e può essere sovrascritto.

Quello che stai facendo è descritto come un comportamento indefinito . Il risultato non può essere previsto.

Le cose con l'output corretto (?) Della console possono cambiare radicalmente se usi :: printf ma non cout. Puoi giocare con il debugger nel seguente codice (testato su x86, 32-bit, MSVisual Studio):

char* foo() 
{
  char buf[10];
  ::strcpy(buf, "TEST”);
  return buf;
}

int main() 
{
  char* s = foo();    //place breakpoint & check 's' varialbe here
  ::printf("%s\n", s); 
}

Dopo essere tornati da una funzione, tutti gli identificatori vengono distrutti anziché i valori conservati in una posizione di memoria e non possiamo individuare i valori senza un identificatore, ma tale posizione contiene ancora il valore memorizzato dalla funzione precedente.

Quindi, qui la funzione foo()restituisce l'indirizzo di ae aviene distrutta dopo aver restituito il suo indirizzo. E puoi accedere al valore modificato tramite quell'indirizzo restituito.

Vorrei fare un esempio del mondo reale:

Supponiamo che un uomo nasconda denaro in un luogo e ti dica il luogo. Dopo un po 'di tempo, l'uomo che ti aveva detto la posizione del denaro muore. Ma hai ancora accesso a quei soldi nascosti.

È un modo "sporco" di usare gli indirizzi di memoria. Quando si restituisce un indirizzo (puntatore) non si sa se appartiene all'ambito locale di una funzione. È solo un indirizzo. Ora che hai invocato la funzione 'pippo', quell'indirizzo (posizione di memoria) di 'a' era già stato allocato nella memoria indirizzabile (sicura, almeno per ora) della tua applicazione (processo). Dopo il ritorno della funzione "pippo", l'indirizzo di "a" può essere considerato "sporco" ma è lì, non ripulito, né disturbato / modificato dalle espressioni in altre parti del programma (almeno in questo caso specifico). Il compilatore AC / C ++ non ti impedisce tale accesso "sporco" (potresti avvertirti, se ti interessa).

Il tuo codice è molto rischioso. Stai creando una variabile locale (che viene considerata distrutta al termine della funzione) e restituisci l'indirizzo di memoria di quella variabile dopo che è stata distrutta.

Ciò significa che l'indirizzo di memoria potrebbe essere valido o meno e il codice sarà vulnerabile a possibili problemi di indirizzo di memoria (ad esempio errore di segmentazione).

Ciò significa che stai facendo una cosa molto brutta, perché stai passando un indirizzo di memoria a un puntatore che non è affatto affidabile.

Considera invece questo esempio e testalo:

int * foo()
{
   int *x = new int;
   *x = 5;
   return x;
}

int main()
{
    int* p = foo();
    std::cout << *p << "\n"; //better to put a new-line in the output, IMO
    *p = 8;
    std::cout << *p;
    delete p;
    return 0;
}

A differenza del tuo esempio, con questo esempio sei:

• allocare memoria per int in una funzione locale
• quell'indirizzo di memoria è ancora valido anche quando la funzione scade, (non viene cancellato da nessuno)
• l'indirizzo di memoria è affidabile (quel blocco di memoria non è considerato libero, quindi non verrà ignorato fino a quando non verrà eliminato)
• l'indirizzo di memoria deve essere eliminato quando non utilizzato. (vedi la cancellazione alla fine del programma)