Perché l'ottimizzatore GCC 6 avanzato interrompe il pratico codice C ++?

GCC 6 ha una nuova funzione di ottimizzazione : presuppone che non thissia sempre nullo e si ottimizza in base a ciò.

La propagazione dell'intervallo di valori ora presuppone che questo puntatore delle funzioni membro C ++ sia non nullo. Ciò elimina i comuni controlli puntatore null ma rompe anche alcune basi di codice non conformi (come Qt-5, Chromium, KDevelop) . Come soluzione temporanea si può usare -fno-delete-null-pointer-checks. Il codice errato può essere identificato usando -fsanitize = undefined.

Il documento di modifica lo definisce chiaramente pericoloso perché rompe una quantità sorprendente di codice utilizzato di frequente.

Perché questo nuovo presupposto spezzerebbe il pratico codice C ++? Ci sono schemi particolari in cui i programmatori negligenti o disinformati si affidano a questo particolare comportamento indefinito? Non riesco a immaginare nessuno che scriva if (this == NULL)perché è così innaturale.

Immagino alla domanda a cui bisogna rispondere perché le persone ben intenzionate dovrebbero scrivere gli assegni in primo luogo.

Il caso più comune è probabilmente se si dispone di una classe che fa parte di una chiamata ricorsiva naturale.

Se tu avessi:

struct Node
{
    Node* left;
    Node* right;
};

in C, potresti scrivere:

void traverse_in_order(Node* n) {
    if(!n) return;
    traverse_in_order(n->left);
    process(n);
    traverse_in_order(n->right);
}

In C ++, è bello renderlo una funzione membro:

void Node::traverse_in_order() {
    // <--- What check should be put here?
    left->traverse_in_order();
    process();
    right->traverse_in_order();
}

All'inizio del C ++ (prima della standardizzazione), si sottolineava che le funzioni membro erano zucchero sintattico per una funzione in cui il thisparametro è implicito. Il codice è stato scritto in C ++, convertito in C equivalente e compilato. Ci sono stati anche esempi espliciti che il confronto thiscon null era significativo e anche il compilatore Cfront originale ne ha tratto vantaggio. Quindi, proveniente da uno sfondo C, la scelta ovvia per il controllo è:

if(this == nullptr) return;      

Nota: Bjarne Stroustrup menziona persino che le regole per thissono cambiate nel corso degli anni qui

E questo ha funzionato su molti compilatori per molti anni. Quando è avvenuta la standardizzazione, questo è cambiato. E più recentemente, i compilatori hanno iniziato a trarre vantaggio dal chiamare una funzione membro in cui l' thisessere nullptrè un comportamento indefinito, il che significa che questa condizione è sempre falsee il compilatore è libero di ometterla.

Ciò significa che per eseguire qualsiasi attraversamento di questo albero, è necessario:

• Fai tutti i controlli prima di chiamare traverse_in_order

  void Node::traverse_in_order() {
      if(left) left->traverse_in_order();
      process();
      if(right) right->traverse_in_order();
  }

  Questo significa anche controllare su OGNI sito di chiamata se si potrebbe avere una radice null.

• Non utilizzare una funzione membro

  Ciò significa che stai scrivendo il vecchio codice di stile C (forse come metodo statico) e lo chiami esplicitamente con l'oggetto come parametro. per esempio. sei tornato a scrivere Node::traverse_in_order(node);piuttosto che node->traverse_in_order();sul sito di chiamata.

• Credo che il modo più semplice / accurato per risolvere questo particolare esempio in modo conforme agli standard sia quello di utilizzare effettivamente un nodo sentinella anziché un nullptr.

  // static class, or global variable
  Node sentinel;
  
  void Node::traverse_in_order() {
      if(this == &sentinel) return;
      ...
  }

Nessuna delle prime due opzioni sembra così allettante, e mentre il codice potrebbe cavarsela, hanno scritto codice cattivo con this == nullptr invece di usare una correzione corretta.

Immagino che sia così che alcune di queste basi di codice si sono evolute per avere this == nullptrcontrolli in esse.

Lo fa perché il codice "pratico" è stato violato e all'inizio ha comportato un comportamento indefinito. Non c'è motivo di usare un null this, se non come una micro-ottimizzazione, di solito molto prematura.

È una pratica pericolosa, poiché la regolazione dei puntatori a causa del passaggio della gerarchia di classi può trasformare un valore null thisin uno non null. Quindi, per lo meno, la classe i cui metodi dovrebbero funzionare con un null thisdeve essere una classe finale senza classe base: non può derivare da nulla e non può essere derivata. Ci stiamo rapidamente allontanando dalla terra pratica a quella brutta .

In termini pratici, il codice non deve essere brutto:

struct Node
{
  Node* left;
  Node* right;
  void process();
  void traverse_in_order() {
    traverse_in_order_impl(this);
  }
private:
  static void traverse_in_order_impl(Node * n)
    if (!n) return;
    traverse_in_order_impl(n->left);
    n->process();
    traverse_in_order_impl(n->right);
  }
};

Se avevi un albero vuoto (es. Root è nullptr), questa soluzione si basa ancora su un comportamento indefinito chiamando traverse_in_order con nullptr.

Se l'albero è vuoto, noto anche come null Node* root, non dovresti chiamare alcun metodo non statico su di esso. Periodo. Va benissimo avere un codice ad albero di tipo C che accetta un puntatore di istanza da un parametro esplicito.

L'argomento qui sembra ridursi in qualche modo alla necessità di scrivere metodi non statici su oggetti che potrebbero essere chiamati da un puntatore a istanza null. Non è necessario. Il modo C-with-objects di scrivere tale codice è ancora molto più bello nel mondo C ++, perché può essere almeno sicuro. Fondamentalmente, il null thisè una tale micro-ottimizzazione, con un campo di applicazione così ristretto, che non consentirlo è perfettamente corretto. Nessuna API pubblica dovrebbe dipendere da un null this.

Il documento di modifica lo definisce chiaramente pericoloso perché rompe una quantità sorprendente di codice utilizzato di frequente.

Il documento non lo definisce pericoloso. Né afferma che rompe una quantità sorprendente di codice . Sottolinea semplicemente alcune basi di codice popolari che afferma di essere noto per fare affidamento su questo comportamento indefinito e che si romperanno a causa della modifica a meno che non venga utilizzata l'opzione alternativa.

Perché questo nuovo presupposto spezzerebbe il pratico codice C ++?

Se il pratico codice c ++ si basa su un comportamento indefinito, le modifiche a quel comportamento indefinito possono interromperlo. Questo è il motivo per cui UB deve essere evitato, anche quando un programma che fa affidamento su di esso sembra funzionare come previsto.

Ci sono schemi particolari in cui i programmatori negligenti o disinformati si affidano a questo particolare comportamento indefinito?

Non so se è un anti- pattern molto diffuso , ma un programmatore non informato potrebbe pensare di poter riparare il loro programma dall'arresto anomalo facendo:

if (this)
    member_variable = 42;

Quando il vero bug sta dereferenziando un puntatore null altrove.

Sono sicuro che se il programmatore è abbastanza disinformato, sarà in grado di escogitare modelli più avanzati (anti) che si basano su questo UB.

Non riesco a immaginare nessuno che scriva if (this == NULL)perché è così innaturale.

Io posso.

Alcuni dei codici "pratici" (modo divertente di scrivere "buggy") che erano rotti apparivano così:

void foo(X* p) {
  p->bar()->baz();
}

e ha dimenticato di rendere conto del fatto che a p->bar()volte restituisce un puntatore nullo, il che significa che il dereferenziare che chiama baz()non è definito.

Non tutto il codice che era rotto conteneva espliciti if (this == nullptr)o if (!p) return;controlli. Alcuni casi erano semplicemente funzioni che non accedevano a nessuna variabile membro e quindi sembravano funzionare correttamente. Per esempio:

struct DummyImpl {
  bool valid() const { return false; }
  int m_data;
};
struct RealImpl {
  bool valid() const { return m_valid; }
  bool m_valid;
  int m_data;
};

template<typename T>
void do_something_else(T* p) {
  if (p) {
    use(p->m_data);
  }
}

template<typename T>
void func(T* p) {
  if (p->valid())
    do_something(p);
  else 
    do_something_else(p);
}

In questo codice quando si chiama func<DummyImpl*>(DummyImpl*)con un puntatore nullo c'è una dereferenza "concettuale" del puntatore da chiamare p->DummyImpl::valid(), ma in effetti quella funzione membro ritorna semplicemente falsesenza accedere *this. Ciò return falsepuò essere integrato e quindi in pratica non è necessario accedere al puntatore. Quindi con alcuni compilatori sembra funzionare bene: non c'è segfault per il dereferenziamento null, p->valid()è falso, quindi il codice chiama do_something_else(p), che controlla i puntatori null e quindi non fa nulla. Non si osservano arresti anomali o comportamenti imprevisti.

Con GCC 6 ricevi ancora la chiamata p->valid(), ma il compilatore ora deduce da quell'espressione che pdeve essere non nulla (altrimenti p->valid()sarebbe un comportamento indefinito) e prende nota di tali informazioni. Le informazioni dedotte vengono utilizzate do_something_else(p)dall'ottimizzatore in modo tale che se la chiamata a viene allineata, il if (p)controllo viene ora considerato ridondante, poiché il compilatore ricorda che non è nullo e quindi incorpora il codice in:

template<typename T>
void func(T* p) {
  if (p->valid())
    do_something(p);
  else {
    // inlined body of do_something_else(p) with value propagation
    // optimization performed to remove null check.
    use(p->m_data);
  }
}

Questo ora dereferenzia davvero un puntatore nullo, e quindi il codice che in precedenza sembrava funzionare smette di funzionare.

In questo esempio è presente il bug func, che dovrebbe aver prima verificato la presenza di null (oppure i chiamanti non avrebbero mai dovuto chiamarlo con null):

template<typename T>
void func(T* p) {
  if (p && p->valid())
    do_something(p);
  else 
    do_something_else(p);
}

Un punto importante da ricordare è che la maggior parte delle ottimizzazioni come questa non è un caso del compilatore che dice "ah, il programmatore ha testato questo puntatore contro null, lo rimuoverò solo per essere fastidioso". Quello che succede è che varie ottimizzazioni run-of-the-mill come inline e propagazione dell'intervallo di valori si combinano per rendere quei controlli ridondanti, perché arrivano dopo un controllo precedente o una dereference. Se il compilatore sa che un puntatore non è nullo nel punto A in una funzione e il puntatore non è cambiato prima di un successivo punto B nella stessa funzione, allora sa che è anche non nullo in B. Quando si verifica l'allineamento i punti A e B potrebbero in realtà essere parti di codice che erano originariamente in funzioni separate, ma ora sono combinate in una parte di codice e il compilatore è in grado di applicare la propria conoscenza del fatto che il puntatore non è nullo in più punti.

Lo standard C ++ è rotto in modi importanti. Sfortunatamente, anziché proteggere gli utenti da questi problemi, gli sviluppatori di GCC hanno scelto di utilizzare comportamenti indefiniti come scusa per implementare ottimizzazioni marginali, anche quando è stato chiaramente spiegato loro quanto sia dannoso.

Qui una persona molto più intelligente di quanto spieghi in dettaglio. (Sta parlando di C ma la situazione è la stessa lì).

• https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ

Perché è dannoso?

La semplice ricompilazione del codice sicuro funzionante in precedenza con una versione più recente del compilatore può introdurre vulnerabilità della sicurezza . Mentre il nuovo comportamento può essere disabilitato con un flag, ovviamente i makefile esistenti non hanno quel flag impostato. E poiché non viene prodotto alcun avviso, per lo sviluppatore non è ovvio che il comportamento precedentemente ragionevole sia cambiato.

In questo esempio, lo sviluppatore ha incluso un controllo per l'overflow di numeri interi, utilizzando assert, che terminerà il programma se viene fornita una lunghezza non valida. Il team GCC ha rimosso il controllo sulla base del fatto che l'overflow di numeri interi non è definito, pertanto è possibile rimuovere il controllo. Ciò ha comportato la ri-vulnerabilità delle istanze reali di questa base di codice dopo che il problema è stato risolto.

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

Leggi tutto. È abbastanza per farti piangere.

OK, ma per quanto riguarda questo?

Molto tempo fa, c'era un idioma abbastanza comune che era simile a questo:

 OPAQUEHANDLE ObjectType::GetHandle(){
    if(this==NULL)return DEFAULTHANDLE;
    return mHandle;

 }

 void DoThing(ObjectType* pObj){
     osfunction(pObj->GetHandle(), "BLAH");
 }

Quindi il linguaggio è: se pObjnon è null, si utilizza l'handle che contiene, altrimenti si utilizza un handle predefinito. Questo è incapsulato nella GetHandlefunzione.

Il trucco è che chiamare una funzione non virtuale in realtà non fa alcun uso del thispuntatore, quindi non vi è alcuna violazione di accesso.

Ancora non capisco

Esiste molto codice scritto in questo modo. Se qualcuno semplicemente lo ricompila, senza cambiare linea, ogni chiamata a DoThing(NULL)è un bug che si arresta in modo anomalo - se sei fortunato.

Se non sei fortunato, le chiamate a bug che si arrestano in modo anomalo diventano vulnerabilità di esecuzione remota.

Questo può accadere anche automaticamente. Hai un sistema di compilazione automatizzato, giusto? L'aggiornamento all'ultimo compilatore è innocuo, giusto? Ma ora non lo è - non se il tuo compilatore è GCC.

OK, diglielo!

Gli è stato detto. Lo stanno facendo nella piena consapevolezza delle conseguenze.

ma perché?

Chi puo 'dirlo? Forse:

• Apprezzano la purezza ideale del linguaggio C ++ rispetto al codice reale
• Credono che le persone dovrebbero essere punite per non aver seguito lo standard
• Non hanno comprensione della realtà del mondo
• Stanno ... introducendo dei bug di proposito. Forse per un governo straniero. Dove vivi? Tutti i governi sono stranieri nella maggior parte del mondo e la maggior parte sono ostili ad alcuni del mondo.

O forse qualcos'altro. Chi puo 'dirlo?