Perché il C ++ ha un "comportamento indefinito" (UB) e altri linguaggi come C # o Java no?

Questo post Stack Overflow elenca un elenco abbastanza completo di situazioni in cui le specifiche del linguaggio C / C ++ dichiarano come "comportamento indefinito". Tuttavia, voglio capire perché altri linguaggi moderni, come C # o Java, non hanno il concetto di "comportamento indefinito". Significa che il progettista del compilatore può controllare tutti gli scenari possibili (C # e Java) o meno (C e C ++)?

Il comportamento indefinito è una di quelle cose che sono state riconosciute come una pessima idea solo a posteriori.

I primi compilatori sono stati grandi risultati e hanno accolto con gioia i miglioramenti rispetto all'alternativa - programmazione del linguaggio macchina o linguaggio assembly. I problemi con questo erano ben noti e le lingue di alto livello furono inventate appositamente per risolvere quei problemi noti. (L'entusiasmo all'epoca era così grande che a volte le HLL erano salutate come "la fine della programmazione" - come se d'ora in poi dovessimo solo scrivere banalmente ciò che volevamo e il compilatore avrebbe fatto tutto il vero lavoro.)

Non è stato fino a dopo che ci siamo resi conto dei nuovi problemi che derivavano dal nuovo approccio. Essere remoti dalla macchina reale su cui viene eseguito il codice significa che c'è più possibilità che le cose silenziosamente non facciano ciò che ci aspettavamo che facessero. Ad esempio, l'allocazione di una variabile in genere lascerebbe indefinito il valore iniziale; questo non è stato considerato un problema, perché non assegneresti una variabile se non volessi conservare un valore, giusto? Sicuramente non era troppo aspettarsi che i programmatori professionisti non dimenticassero di assegnare il valore iniziale, vero?

Si è scoperto che con le basi di codice più grandi e le strutture più complicate che sono diventate possibili con sistemi di programmazione più potenti, sì, molti programmatori avrebbero effettivamente commesso tali sviste di volta in volta, e il conseguente comportamento indefinito è diventato un grave problema. Ancora oggi, la maggior parte delle perdite di sicurezza da minuscole a orribili sono il risultato di comportamenti indefiniti in una forma o nell'altra. (La ragione è che di solito il comportamento indefinito è in realtà molto definito dalle cose al livello inferiore successivo sull'informatica, e gli attaccanti che capiscono quel livello possono usare quel margine di manovra per creare un programma non solo cose indesiderate, ma esattamente le cose essi intendono.)

Da quando l'abbiamo riconosciuto, c'è stato un impulso generale a bandire comportamenti indefiniti da linguaggi di alto livello, e Java è stato particolarmente accurato al riguardo (il che è stato relativamente facile dal momento che è stato progettato per funzionare sulla propria macchina virtuale appositamente progettata). Le lingue meno recenti come C non possono essere facilmente adattate in questo modo senza perdere la compatibilità con l'enorme quantità di codice esistente.

Modifica: come sottolineato, l'efficienza è un'altra ragione. Comportamento indefinito significa che gli autori di compilatori hanno molto margine di manovra per sfruttare l'architettura di destinazione in modo che ogni implementazione riesca a implementare più rapidamente possibile di ogni funzionalità. Ciò era più importante sulle macchine poco potenti di ieri rispetto a oggi, quando lo stipendio del programmatore è spesso il collo di bottiglia per lo sviluppo del software.

Fondamentalmente perché i progettisti di Java e di linguaggi simili non volevano comportamenti indefiniti nella loro lingua. Questo è stato un compromesso: consentire comportamenti indefiniti ha il potenziale per migliorare le prestazioni, ma i progettisti del linguaggio hanno dato priorità alla sicurezza e alla prevedibilità più elevate.

Ad esempio, se si assegna una matrice in C, i dati non sono definiti. In Java, tutti i byte devono essere inizializzati su 0 (o su qualche altro valore specificato). Ciò significa che il runtime deve passare sull'array (un'operazione O (n)), mentre C può eseguire l'allocazione in un istante. Quindi C sarà sempre più veloce per tali operazioni.

Se il codice che utilizza l'array lo popolerà comunque prima di leggere, questo è sostanzialmente uno sforzo sprecato per Java. Ma nel caso in cui il codice venga letto per primo, si ottengono risultati prevedibili in Java ma risultati imprevedibili in C.

Il comportamento indefinito consente un'ottimizzazione significativa, dando al compilatore la latitudine di fare qualcosa di strano o inaspettato (o persino normale) a determinati confini o altre condizioni.

Vedi http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Uso di una variabile non inizializzata: questa è comunemente nota come fonte di problemi nei programmi C e ci sono molti strumenti per catturarli: dagli avvisi del compilatore agli analizzatori statici e dinamici. Ciò migliora le prestazioni non richiedendo l'inizializzazione di tutte le variabili quando entrano nell'ambito (come fa Java). Per la maggior parte delle variabili scalari, ciò comporterebbe un piccolo sovraccarico, ma gli array di stack e la memoria malloc incorrerebbero in un memset dell'archiviazione, che potrebbe essere piuttosto costoso, soprattutto perché l'archiviazione è di solito completamente sovrascritta.

Overflow intero con segno: se l'aritmetica su un tipo 'int' (ad esempio) trabocca, il risultato non è definito. Un esempio è che "INT_MAX + 1" non è garantito per essere INT_MIN. Questo comportamento consente alcune classi di ottimizzazioni che sono importanti per alcuni codici. Ad esempio, sapere che INT_MAX + 1 non è definito consente di ottimizzare "X + 1> X" su "vero". Conoscere la moltiplicazione "impossibile" overflow (perché non sarebbe definito) consentire l'ottimizzazione di "X * 2/2" su "X". Mentre questi possono sembrare banali, questo genere di cose sono comunemente esposte dall'espansione e dall'espansione macro. Un'ottimizzazione più importante che ciò consente è per i cicli "<=" come questo:

for (i = 0; i <= N; ++i) { ... }

In questo ciclo, il compilatore può presumere che il ciclo ripeterà esattamente N + 1 volte se "i" non è definito su overflow, il che consente di avviare un'ampia gamma di ottimizzazioni del ciclo. D'altra parte, se la variabile è definita in andare a capo di un overflow, quindi il compilatore deve presumere che il ciclo sia probabilmente infinito (cosa che succede se N è INT_MAX) - che quindi disabilita queste importanti ottimizzazioni del ciclo. Ciò riguarda in particolare le piattaforme a 64 bit poiché tanto codice utilizza "int" come variabili di induzione.

All'inizio C, c'era molto caos. Diversi compilatori hanno trattato la lingua in modo diverso. Quando c'era interesse a scrivere una specifica per il linguaggio, quella specifica avrebbe dovuto essere abbastanza retrocompatibile con la C su cui i programmatori si affidavano ai loro compilatori. Ma alcuni di questi dettagli non sono portatili e non hanno senso in generale, ad esempio assumendo una particolare endianess o layout di dati. Lo standard C pertanto riserva molti dettagli come comportamento indefinito o specificato dall'implementazione, che lascia molta flessibilità agli autori di compilatori. C ++ si basa su C e presenta anche un comportamento indefinito.

Java ha cercato di essere un linguaggio molto più sicuro e molto più semplice di C ++. Java definisce la semantica del linguaggio in termini di una macchina virtuale completa. Ciò lascia poco spazio a comportamenti indefiniti, d'altra parte rende requisiti che possono essere difficili da realizzare per un'implementazione Java (ad es. Che le assegnazioni di riferimento devono essere atomiche o come funzionano gli interi). Laddove Java supporta operazioni potenzialmente non sicure, in genere vengono controllate dalla macchina virtuale in fase di esecuzione (ad esempio, alcuni cast).

I linguaggi JVM e .NET semplificano:

1. Non devono essere in grado di lavorare direttamente con l'hardware.
2. Devono solo funzionare con moderni sistemi desktop e server o dispositivi ragionevolmente simili, o almeno dispositivi progettati per loro.
3. Possono imporre la garbage collection per tutta la memoria e l'inizializzazione forzata, ottenendo così la sicurezza del puntatore.
4. Sono stati specificati da un singolo attore che ha anche fornito la singola implementazione definitiva.
5. Possono scegliere la sicurezza piuttosto che le prestazioni.

Ci sono buoni punti per le scelte però:

1. La programmazione dei sistemi è un gioco completamente diverso, e invece l'ottimizzazione senza compromessi per la programmazione delle applicazioni è ragionevole.
2. Certo, c'è sempre meno hardware esotico, ma i piccoli sistemi embedded sono qui per rimanere.
3. GC non è adatto a risorse non fungibili e scambia molto più spazio per buone prestazioni. E la maggior parte (ma non quasi) delle inizializzazioni forzate può essere ottimizzata.
4. Ci sono vantaggi per una maggiore concorrenza, ma i comitati significano compromesso.
5. Tutti questi controlli dei limiti si sommano, anche se la maggior parte può essere ottimizzata via. I controlli dei puntatori null possono essere effettuati principalmente bloccando l'accesso per zero overhead grazie allo spazio di indirizzi virtuale, sebbene l'ottimizzazione sia ancora inibita.

Laddove vengono forniti i tratteggi di fuga, questi invitano nuovamente a comportarsi in modo indefinito. Ma almeno sono generalmente utilizzati solo in pochi tratti molto brevi, che sono quindi più facili da verificare manualmente.

Java e C # sono caratterizzati da un fornitore dominante, almeno all'inizio del loro sviluppo. (Rispettivamente Sun e Microsoft). C e C ++ sono diversi; hanno avuto molteplici implementazioni concorrenti sin dall'inizio. C funzionava anche su piattaforme hardware esotiche. Di conseguenza, c'è stata una variazione tra le implementazioni. I comitati ISO che hanno standardizzato C e C ++ potrebbero concordare un grande denominatore comune, ma ai margini in cui le implementazioni differiscono gli standard lasciano spazio all'implementazione.

Questo anche perché la scelta di un comportamento potrebbe essere costosa per le architetture hardware che sono orientate verso un'altra scelta: l'endianness è la scelta ovvia.

Il vero motivo si riduce a una differenza fondamentale nell'intento tra C e C ++ da un lato, e Java e C # (solo per un paio di esempi) dall'altro. Per ragioni storiche, gran parte della discussione qui parla di C piuttosto che di C ++, ma (come probabilmente già saprai) C ++ è un discendente abbastanza diretto di C, quindi ciò che dice di C si applica ugualmente a C ++.

Sebbene siano in gran parte dimenticati (e la loro esistenza a volte addirittura negata), le primissime versioni di UNIX sono state scritte in linguaggio assembly. Gran parte (se non esclusivamente) lo scopo originale di C era il port UNIX dal linguaggio assembly a un linguaggio di livello superiore. Parte dell'intento era scrivere il più possibile del sistema operativo in un linguaggio di livello superiore - o guardarlo dall'altra direzione, per ridurre al minimo la quantità che doveva essere scritta in linguaggio assembly.

A tale scopo, C doveva fornire quasi lo stesso livello di accesso all'hardware del linguaggio assembly. Il PDP-11 (per un esempio) ha mappato i registri I / O su indirizzi specifici. Ad esempio, avresti letto una posizione di memoria per verificare se era stato premuto un tasto sulla console di sistema. È stato impostato un bit in quella posizione quando c'erano dati in attesa di essere letti. Quindi leggere un byte da un'altra posizione specificata per recuperare il codice ASCII del tasto che era stato premuto.

Allo stesso modo, se si desidera stampare alcuni dati, è necessario controllare un'altra posizione specificata e quando il dispositivo di output era pronto, scrivere i dati ancora un'altra posizione specificata.

Per supportare la scrittura di driver per tali dispositivi, C ha permesso di specificare una posizione arbitraria utilizzando un tipo intero, convertirlo in un puntatore e leggere o scrivere quella posizione in memoria.

Naturalmente, questo ha un problema piuttosto grave: non tutte le macchine sulla terra hanno la sua memoria identica a un PDP-11 dei primi anni '70. Quindi, quando prendi quel numero intero, lo converti in un puntatore e poi leggi o scrivi tramite quel puntatore, nessuno può fornire alcuna ragionevole garanzia su ciò che otterrai. Solo per un esempio ovvio, la lettura e la scrittura possono essere associate a registri separati nell'hardware, quindi tu (contrariamente alla memoria normale) se scrivi qualcosa, quindi prova a rileggerlo, ciò che leggi potrebbe non corrispondere a ciò che hai scritto.

Vedo alcune possibilità che lascia:

1. Definisci un'interfaccia per tutto l'hardware possibile: specifica gli indirizzi assoluti di tutte le posizioni che potresti voler leggere o scrivere per interagire con l'hardware in qualsiasi modo.
2. Proibire quel livello di accesso e decretare che chiunque voglia fare tali cose deve usare il linguaggio assembly.
3. Consenti alle persone di farlo, ma lascia loro la possibilità di leggere (ad esempio) i manuali per l'hardware a cui sono destinati e di scrivere il codice per adattarlo all'hardware che stanno utilizzando.

Di questi, 1 sembra sufficientemente assurdo da non meritare ulteriori discussioni. 2 sta praticamente eliminando l'intento di base della lingua. Ciò lascia la terza opzione come essenzialmente l'unica che potrebbero ragionevolmente considerare.

Un altro punto che emerge abbastanza frequentemente sono le dimensioni dei tipi interi. C prende la "posizione" che intdovrebbe essere la dimensione naturale suggerita dall'architettura. Quindi, se sto programmando un VAX a 32 bit, intprobabilmente dovrebbe essere 32 bit, ma se sto programmando un Univac a 36 bit, intprobabilmente dovrebbe essere 36 bit (e così via). Probabilmente non è ragionevole (e potrebbe anche non essere possibile) scrivere un sistema operativo per un computer a 36 bit utilizzando solo tipi di dimensioni garantite di multipli di 8 bit. Forse sono solo superficiale, ma mi sembra che se stavo scrivendo un sistema operativo per una macchina a 36 bit, probabilmente avrei voluto usare un linguaggio che supportasse un tipo a 36 bit.

Da un punto di vista linguistico, questo porta a comportamenti ancora più indefiniti. Se prendo il valore più grande che si adatta a 32 bit, cosa accadrà quando aggiungo 1? Sull'hardware tipico a 32 bit, verrà eseguito il roll over (o eventualmente gettato una sorta di errore hardware). D'altra parte, se è in esecuzione su hardware a 36 bit, semplicemente ... ne aggiungerà uno. Se la lingua supporterà la scrittura di sistemi operativi, non puoi garantire nessuno dei due comportamenti: devi solo consentire che le dimensioni dei tipi e il comportamento dell'overflow possano variare l'uno dall'altro.

Java e C # possono ignorare tutto ciò. Non intendono supportare la scrittura di sistemi operativi. Con loro, hai un paio di scelte. Uno è quello di fare in modo che l'hardware supporti ciò di cui hanno bisogno, poiché richiedono tipi da 8, 16, 32 e 64 bit, basta creare hardware che supporti quelle dimensioni. L'altra ovvia possibilità è che la lingua venga eseguita solo su altri software che forniscono l'ambiente che desiderano, indipendentemente da ciò che l'hardware sottostante potrebbe desiderare.

Nella maggior parte dei casi, questa non è davvero una scelta o / o. Piuttosto, molte implementazioni fanno un po 'di entrambi. Normalmente si esegue Java su una JVM in esecuzione su un sistema operativo. Più spesso, il sistema operativo è scritto in C e la JVM in C ++. Se la JVM è in esecuzione su una CPU ARM, è abbastanza probabile che la CPU includa le estensioni Jazelle di ARM, per adattare l'hardware più vicino alle esigenze di Java, quindi è necessario fare meno nel software e il codice Java funziona più velocemente (o meno lentamente, comunque).

Sommario

C e C ++ hanno un comportamento indefinito, perché nessuno ha definito un'alternativa accettabile che permetta loro di fare ciò che intendono fare. C # e Java adottano un approccio diverso, ma tale approccio si adatta male (se non del tutto) agli obiettivi di C e C ++. In particolare, nessuno dei due sembra fornire un modo ragionevole per scrivere software di sistema (come un sistema operativo) sull'hardware scelto arbitrariamente. Entrambi in genere dipendono dalle funzionalità fornite dal software di sistema esistente (solitamente scritto in C o C ++) per svolgere il proprio lavoro.

Gli autori dello standard C si aspettavano che i loro lettori riconoscessero qualcosa che pensavano fosse ovvio e alludevano al loro razionale pubblicato, ma non hanno detto apertamente: il Comitato non avrebbe dovuto ordinare agli scrittori di compilatori di soddisfare le esigenze dei loro clienti, poiché i clienti dovrebbero sapere meglio del Comitato quali sono le loro esigenze. Se è ovvio che ci si aspetta che i compilatori per determinati tipi di piattaforme elaborino un costrutto in un certo modo, a nessuno dovrebbe importare se lo Standard afferma che il costrutto invoca un comportamento indefinito. L'incapacità dello Standard di imporre che i compilatori conformi elaborino utilmente un pezzo di codice non implica in alcun modo che i programmatori dovrebbero essere disposti ad acquistare compilatori che non lo fanno.

Questo approccio alla progettazione del linguaggio funziona molto bene in un mondo in cui gli autori di compilatori devono vendere i loro prodotti a clienti paganti. Cade completamente a pezzi in un mondo in cui gli autori di compilatori sono isolati dagli effetti del mercato. È dubbio che esisteranno mai le condizioni di mercato adeguate per orientare una lingua nel modo in cui avevano guidato quella che è diventata popolare negli anni '90, e ancor più dubbio che qualsiasi progettista di lingua sana vorrebbe fare affidamento su tali condizioni di mercato.

C ++ e c hanno entrambi standard descrittivi (le versioni ISO, comunque).

Che esistono solo per spiegare come funzionano le lingue e per fornire un unico riferimento su quale sia la lingua. In genere, i fornitori di compilatori e gli scrittori di biblioteche aprono la strada e alcuni suggerimenti vengono inclusi nello standard ISO principale.

Java e C # (o Visual C #, che presumo tu intenda) hanno standard prescrittivi . Ti dicono cosa c'è nella lingua in modo definitivo in anticipo, come funziona e cosa è considerato comportamento consentito.

Ancora più importante, Java ha effettivamente una "implementazione di riferimento" in Open-JDK. (Penso che Roslyn conti come l'implementazione di riferimento di Visual C #, ma non sono riuscito a trovare una fonte per quello.)

Nel caso di Java, se c'è qualche ambiguità nello standard e Open-JDK lo fa in un certo modo. Il modo in cui Open-JDK lo fa è lo standard.

Il comportamento indefinito consente al compilatore di generare codice molto efficiente su una varietà di architetti. La risposta di Erik menziona l'ottimizzazione, ma va oltre.

Ad esempio, gli overflow firmati sono comportamenti indefiniti in C. In pratica, si prevedeva che il compilatore generasse un semplice codice operativo aggiuntivo addizionale per l'esecuzione della CPU, e il comportamento sarebbe qualunque cosa facesse quella particolare CPU.

Ciò ha permesso a C di funzionare molto bene e produrre codice molto compatto sulla maggior parte delle architetture. Se lo standard avesse specificato che gli interi con segno dovevano traboccare in un certo modo, le CPU che si comportavano diversamente avrebbero avuto bisogno di molto più codice per generare una semplice aggiunta firmata.

Questa è la ragione di gran parte del comportamento indefinito in C, e perché cose come la dimensione di intvariano tra i sistemi. Intdipende dall'architettura e generalmente è selezionato per essere il tipo di dati più veloce ed efficiente che è più grande di un char.

Quando C era nuovo queste considerazioni erano importanti. I computer erano meno potenti, spesso con velocità e memoria di elaborazione limitate. La C è stata utilizzata laddove le prestazioni erano davvero importanti e gli sviluppatori dovevano comprendere come i computer funzionassero abbastanza bene da sapere quali comportamenti non definiti sarebbero stati effettivamente sui loro sistemi particolari.

Linguaggi successivi come Java e C # hanno preferito eliminare il comportamento indefinito rispetto alle prestazioni non elaborate.

In un certo senso, anche Java ce l'ha. Supponiamo che tu abbia fornito un comparatore errato ad Arrays.sort. Può lanciare un'eccezione e lo rileva. Altrimenti ordinerà un array in qualche modo che non è garantito per essere particolare.

Allo stesso modo se si modificano le variabili da più thread i risultati sono anche imprevedibili.

Il C ++ è appena andato oltre per creare un numero indefinito di situazioni (o piuttosto Java ha deciso di definire più operazioni) e di avere un nome per esso.