UB in C: GCC può eseguire una funzione mai chiamata

Con GCC 16.2 con l’opzione -O1, l’uso di std::unreachable() ha prodotto codice che esegue una funzione mai chiamata nel sorgente. L’esempio, pubblicato su habets.se, nasce per contestare l’idea che con comportamento indefinito “al massimo arriva un segfault”. L’autore scrive: è falso¹.

Il frammento parte da una variabile globale volatile. Il commento nel codice chiede di immaginare un dispositivo a memoria mappata che controlla “motors and gears and stuff”. Il sorgente definisce due funzioni: serve_hot_chocolate() scrive 42 in device_command e poi chiama std::unreachable(). explode() scrive 3 nella stessa variabile¹.

Nel post compare la definizione di std::unreachable(): “Invokes undefined behavior at a given point.” Il cuore dell’esempio è qui. L’autore mostra cosa succede quando si dichiara quel punto come irraggiungibile e si compila con le impostazioni indicate¹.

Compilando con GCC 16.2 e -O1, l’assembly riportato è sintetico: serve_hot_chocolate() contiene una scrittura di 42 su device_command. explode() contiene una scrittura di 3, poi il ritorno. device_command risulta inizializzato a zero¹.

Subito dopo, l’autore annota l’effetto che vuole evidenziare: “Exploding chocolate! The function explode() will be executed, even though it was never called!” Il comportamento osservato è l’esecuzione di explode() senza una chiamata esplicita nel sorgente. È la conseguenza dell’UB introdotto con std::unreachable() nel flusso mostrato¹.

I nomi nel codice chiariscono l’intento dell’esempio. serve_hot_chocolate() imposta 42, poi dichiara “qui non si arriva mai”. explode() imposta 3. La variabile condivisa è volatile. Il commento la presenta come registro di un dispositivo a memoria mappata, così la differenza tra 42 e 3 sarebbe osservabile in uscita verso “motors and gears and stuff”¹.

L’autore aggiunge un secondo spunto. Alcune persone insistono che dereferenziare un puntatore nullo sia “fine”. “It’ll just try to access address zero!” Il post introduce anche questo tema come parte della stessa tesi: l’idea che l’UB sia innocuo non regge ai fatti mostrati¹.

Il punto di partenza del post è netto: dopo un precedente intervento su comportamento indefinito in C, alcuni sostenevano che si sa cosa farà il codice e che, nel peggiore dei casi, si ottiene un segfault. L’autore replica con un caso concreto, completo di sorgente e listato assembly con le esatte condizioni di compilazione: GCC 16.2 e -O1¹.

Nel materiale pubblicato c’è tutto quello che serve a riprodurre l’osservazione: il codice con std::unreachable(), la variabile volatile device_command impostata a 42 in serve_hot_chocolate() e a 3 in explode(), e l’output in assembly che accompagna la spiegazione. La chiosa è nella frase già citata: explode() viene eseguita “even though it was never called!”¹.