Dlaczego enhanced GCC 6 optimizer łamie praktyczny kod C++?

Robi to, ponieważ "praktyczny" kod został złamany i wymagał niezdefiniowanego zachowania. Nie ma powodu, aby używać null this, innego niż mikro-optymalizacja, zwykle bardzo przedwczesna.

Jest to niebezpieczna praktyka, ponieważ korekta wskaźników ze względu na przechodzenie hierarchii klas może zmienić null this w non-null. Tak więc, klasa, której metody mają działać z null this musi być klasą końcową bez klasy bazowej: it nie można z niczego czerpać i nie można z tego czerpać. Szybko odchodzimy z praktycznego do brzydkiej krainy .

W praktyce kod nie musi być brzydki:

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);
  }
};

Jeśli masz puste drzewo (np. root to nullptr), To rozwiązanie nadal opiera się na niezdefiniowanym zachowaniu przez wywołanie traverse_in_order z nullptr.

Jeśli drzewo jest puste, a. k. a. A null Node* root, nie powinieneś wywoływać żadnych niestatycznych metod na nim. Kropka. Dobrze jest mieć podobny do C kod drzewa, który pobiera wskaźnik instancji za pomocą jawnego parametru.

Tutaj argument sprowadza się do konieczności zapisu niestatycznych metod na obiektach, które można wywołać ze wskaźnika instancji null. Nie ma takiej potrzeby. Sposób pisania takiego kodu w C-with-objects jest nadal o wiele ładniejszy w świecie C++, ponieważ może być co najmniej bezpieczny. Zasadniczo null this jest taką mikro-optymalizacją, z tak wąskim polem zastosowania, to jest IMHO w porządku. Żadne publiczne API nie powinno zależeć od null this.

Dokument zmian wyraźnie określa to jako niebezpieczne, ponieważ łamie zaskakującą ilość często używanego kodu.

Dokument nie nazywa tego niebezpiecznym. Nie twierdzi też, że łamie zaskakującą ilość kodu . Po prostu wskazuje kilka popularnych baz kodu, które, jak twierdzi, są znane z tego, że opierają się na tym nieokreślonym zachowaniu I ulegną zniszczeniu z powodu zmiany, chyba że zostanie użyta opcja obejścia problemu.

Dlaczego to nowe założenie złamać praktyczny kod C++?

Jeśli praktyczny kod c++ opiera się na niezdefiniowanym zachowaniu, to zmiany w tym niezdefiniowanym zachowaniu mogą go złamać. Dlatego należy unikać UB, nawet jeśli program oparty na nim wydaje się działać zgodnie z przeznaczeniem.

Czy istnieją konkretne wzorce, w których nieostrożni lub niedoinformowani Programiści polegają na tym konkretnym nieokreślonym zachowaniu?

Nie wiem czy jest szeroko rozpowszechniony anty -wzorzec, ale niedoinformowany programista może pomyśleć, że mogą naprawić swój program z awarii, wykonując:

if (this)
    member_variable = 42;

Gdy rzeczywisty błąd przekierowuje wskaźnik null gdzie indziej.

Jestem pewien, że jeśli programista będzie wystarczająco niedoinformowany, będzie w stanie wymyślić bardziej zaawansowane (anty) wzorce, które opierają się na tym UB.

Nie wyobrażam sobie, żeby ktoś pisał if (this == NULL) ponieważ to takie nienaturalne.

Niektóre" praktyczne "(zabawny sposób na pisanie" buggy") kody, które zostały złamane, wyglądały tak:]}

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

I zapomniał wyjaśnić fakt, że p->bar() czasami zwraca wskaźnik null, co oznacza, że odwołanie go do wywołania baz() jest niezdefiniowane.

Nie wszystkie złamane kody zawierały jawne if (this == nullptr) lub if (!p) return; kontrole. Niektóre przypadki były po prostu funkcjami, które nie miały dostępu do żadnych zmiennych członkowskich, więc okazało się działać poprawnie. Na przykład:

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);
}

W tym kodzie, gdy wywołujesz {[8] } ze wskaźnikiem null, istnieje "koncepcyjna" dereferencja wskaźnika do wywołania p->DummyImpl::valid(), ale w rzeczywistości funkcja member zwraca false bez dostępu do *this. To return false może być inlined, więc w praktyce wskaźnik nie musi być w ogóle dostępny. Więc z niektórymi kompilatorami wydaje się działać OK: nie ma segfault dla dereferencji null, p->valid() jest false, więc kod wywołuje do_something_else(p), który sprawdza wskaźniki null, i tak robi nic. Nie obserwuje się awarii ani nieoczekiwanego zachowania.

Z GCC 6 nadal otrzymujesz wywołanie p->valid(), ale kompilator wnioskuje z tego wyrażenia, że p musi być nie-null (w przeciwnym razie p->valid() byłoby niezdefiniowanym zachowaniem) i notuje te informacje. Ta wywnioskowana informacja jest używana przez optymalizator tak, że jeśli wywołanie do_something_else(p) zostanie zainlinowane, sprawdzenie if (p) jest teraz uważane za zbędne, ponieważ kompilator pamięta, że nie jest null, a więc wprowadza kod do:

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);
  }
}

To teraz naprawdę nie dereference wskaźnik null, i tak kod, który wcześniej wydawał się działać przestaje działać.

W tym przykładzie błąd znajduje się w func, który powinien najpierw sprawdzić, czy nie ma null (lub wywoływacze nigdy nie powinni wywoływać go z null):

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

Ważnym punktem do zapamiętania jest to, że większość optymalizacji tego typu nie jest przypadkiem, gdy kompilator mówi: "ach, programista testował ten wskaźnik przeciwko null, usunę go tylko po to, aby być irytujące". Dzieje się tak, że różne optymalizacje run-of-the-mill, takie jak inlining i propagacja zakresu wartości, łączą się, aby te kontrole były zbędne, ponieważ pojawiają się po wcześniejszym sprawdzeniu lub dereferencji. Jeśli kompilator wie, że wskaźnik nie jest null w punkcie a w funkcji, a wskaźnik nie jest zmieniany przed późniejszym punktem B w tej samej funkcji, to wie, że jest również null w punkcie B. gdy następuje inlining, punkty A i B mogą być fragmentami kodu, które pierwotnie były w funkcji. osobne funkcje, ale są teraz połączone w jeden kawałek kodu, a kompilator jest w stanie zastosować swoją wiedzę, że wskaźnik nie jest null w wielu miejscach. Jest to podstawowa, ale bardzo ważna optymalizacja, a gdyby Kompilatory tego nie zrobiły, codzienny kod byłby znacznie wolniejszy, a ludzie narzekaliby na niepotrzebne gałęzie, aby wielokrotnie testować te same warunki.

Standard C++ jest łamany w istotny sposób. Niestety, zamiast chronić użytkowników przed tymi problemami, deweloperzy GCC zdecydowali się użyć niezdefiniowanego zachowania jako pretekstu do wdrożenia marginalnych optymalizacji, nawet jeśli zostało im jasno wyjaśnione, jak szkodliwe jest to.

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

Po prostu przekompilowanie wcześniej działającego, bezpiecznego kodu z nowszą wersją kompilatora może wprowadzić luki w zabezpieczeniach . Podczas gdy nowe zachowanie można wyłączyć za pomocą flagi, istniejące pliki Makefile oczywiście nie mają tej flagi ustawionej. A ponieważ nie ma ostrzeżenia, nie jest oczywiste dla dewelopera, że dotychczas rozsądne zachowanie uległo zmianie.

W tym przykładzie programista włączył sprawdzanie przepełnienia liczb całkowitych, używając assert, które zakończy program, jeśli podana zostanie Nieprawidłowa długość. Zespół GCC usunął sprawdzanie na podstawie tego, że przepełnienie integer jest niezdefiniowane, dlatego sprawdzanie może zostać usunięte. Spowodowało to, że prawdziwe in-the-wild instancje tej bazy kodowej zostały ponownie narażone po problemie naprawione.

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

Dawno temu, był dość powszechny idiom, który wyglądał mniej więcej tak:

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

 }

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

Więc idiom brzmi: Jeśli pObj nie jest null, używasz uchwytu, który zawiera, w przeciwnym razie używasz domyślnego uchwytu. Jest to zamknięte w funkcji GetHandle.

Sztuczka polega na tym, że wywołanie nie-wirtualna funkcja nie wykorzystuje wskaźnika this, więc nie ma naruszenia dostępu.

I still don ' t get it

Istnieje wiele kodu, który jest napisany w ten sposób. Jeśli ktoś po prostu ją przekompiluje, bez zmiany linii, każde wywołanie DoThing(NULL) jest błędem-jeśli masz szczęście.

Jeśli nie masz szczęścia, połączenia z awariami stają się lukami w zdalnej realizacji.

Kto może powiedzieć? Być może:

[11]}cenią idealną czystość języka C++ nad rzeczywistym kodem Wierzą, że ludzie powinni być karani za nieprzestrzeganie standardu.]}
• nie mają zrozumienie rzeczywistości świata
Są ... celowo Wprowadzamy błędy. Może dla obcego rządu. Gdzie mieszkasz? Wszystkie rządy są obce większości świata, a większość jest wrogo nastawiona do części świata.