Overflow intero e comportamento indefinito

Question

Ci sono molte domande sul rilevamento dell'overflow dei numeri interi PRIMA dell'effettiva aggiunta/sottostringa a causa del possibile undefined behavior. Quindi, la mia domanda è

Perché produrrà questo undefined behavior in primo luogo?

posso pensare 2 cause:

1) Un processore che genera un'eccezione in questo caso. Certo, può essere disattivato e molto probabilmente un CRT ben scritto lo farà.

2) Un processore che utilizza altre rappresentazioni binarie di numeri (1 complemento? Base 10?). In tal caso il comportamento indefinito si manifesterà come risultato diverso (ma non si bloccherà!). Bene, potremmo vivere con quello.

Quindi, perché qualcuno dovrebbe evitare di causarlo? Mi sto perdendo qualcosa?

Answer 1

Sebbene maggior CPU moderni usano complemento a 2, e risultati integer overflow nei prevedibile avvolgente modulo, questo non è affatto universale - a mantenere il linguaggio sufficientemente generale che può essere utilizzato su più ampia gamma di architetture è meglio specificare che l'overflow integer è UB.

Answer 2

I bit undefined behavior nella specifica implicano l'ottimizzazione del compilatore. Per esempio:

if (a > 0 && b > 0) { 
    if (a + b <= 0) { 
     // this branch may be optimized out by compiler 
    } else { 
     // this branch will always run 
    } 
} 

moderna compilatori C non sono così semplici, è fare un sacco di indovinare e ottimizzazione.

Answer 3

Penso che la tua ipotesi 1) che questo possa essere disattivato per un determinato processore è stato falso su almeno un'architettura storica importante, il CDC, se la mia memoria è corretta.

Answer 4

Mentre il motivo storico con overflow firmato era specificato come comportamento non definito erano probabilmente queste false rappresentazioni legacy (un complemento/segno di magnitudo) e interruzioni di overflow, la ragione moderna per cui il comportamento indefinito rimane è l'ottimizzazione. Come accennato a J-16 SDiZ, il fatto che l'overflow firmato sia un comportamento indefinito consente al compilatore di ottimizzare alcuni condizionali la cui verità algebrica (ma non necessariamente verità a livello di rappresentazione) è già stabilita da un ramo precedente. Può anche consentire al compilatore di semplificare algebricamente alcune espressioni (in particolare quelle che coinvolgono moltiplicazione o divisione) in modi che potrebbero dare risultati diversi rispetto all'ordine di valutazione originariamente scritto se una sottoespressione contiene un overflow, poiché il compilatore può supporre che l'overflow non succede con gli operandi che gli hai dato.

L'altro enorme esempio di comportamento non definito allo scopo di consentire l'ottimizzazione è le regole di aliasing.