Warum kann der C-Compiler das Ändern des Werts eines konstanten Zeigers nicht optimieren, wenn davon ausgegangen wird, dass zwei Zeiger auf dieselbe Variable illegal/UB wären?

Kürzlich bin ich über einen Vergleich zwischen Rust und C gestolpert und sie verwenden den folgenden Code:

bool f(int* a, const int* b) {
  *a = 2;
  int ret = *b;
  *a = 3;
  return ret != 0;
}

In Rust (gleicher Code, aber mit Rust-Syntax) erzeugt es den folgenden Assembler-Code:

    cmp      dword ptr [rsi], 0 
    mov      dword ptr [rdi], 3 
    setne al                    
    ret

Während es mit gcc Folgendes erzeugt:

   mov      DWORD PTR [rdi], 2   
   mov      eax, DWORD PTR [rsi]
   mov      DWORD PTR [rdi], 3        
   test     eax, eax                  
   setne al                           
   ret

Der Text behauptet, dass die C-Funktion die erste Zeile nicht wegoptimieren kann, weil a und b könnte auf die gleiche Nummer zeigen. In Rust ist dies nicht erlaubt, damit der Compiler es wegoptimieren kann.

Nun zu meiner Frage:

Die Funktion dauert a const int* was ein Zeiger auf eine Konstante int ist. Ich habe diese Frage gelesen und sie besagt, dass das Ändern einer Konstante int mit einem Zeiger zu einer Compiler-Warnung und zur schlimmsten Besetzung in UB führen sollte.

Könnte diese Funktion zu einem UB führen, wenn ich sie mit zwei Zeigern auf dieselbe Ganzzahl aufrufe?

Warum kann der C-Compiler nicht die erste Zeile wegoptimieren, unter der Annahme, dass zwei Zeiger auf dieselbe Variable illegal/UB wären?

Link zu Godbolt

Warum kann der C-Compiler nicht die erste Zeile wegoptimieren, unter der Annahme, dass zwei Zeiger auf dieselbe Variable illegal/UB wären?

Weil Sie den C-Compiler nicht dazu angewiesen haben, dass er diese Annahme machen darf.

C hat einen Typqualifizierer für genau diesen Namen restrict was ungefähr bedeutet: dieser Zeiger überschneidet sich nicht mit anderen Zeigern (nicht exaktaber spiel mit).

Die Assembly-Ausgabe für

bool f(int* restrict a, const int* b) {
  *a = 2;
  int ret = *b;
  *a = 3;
  return ret != 0;
}

ist

        mov     eax, DWORD PTR [rsi]
        mov     DWORD PTR [rdi], 3
        test    eax, eax
        setne   al
        ret

… was die Zuordnung entfernt/optimiert *a = 2

Aus https://en.wikipedia.org/wiki/Restrict

In der Programmiersprache C ist „restrict“ ein Schlüsselwort, das in Zeigerdeklarationen verwendet werden kann. Durch Hinzufügen dieses Typqualifizierers weist ein Programmierer den Compiler darauf hin, dass für die Lebensdauer des Zeigers nur der Zeiger selbst oder ein direkt davon abgeleiteter Wert (z. B. Zeiger + 1) verwendet wird, um auf das Objekt zuzugreifen, auf das er zeigt.

Die Funktion int f(int *a, const int *b); verspricht, den Inhalt nicht zu ändern b durch diesen Zeiger… Es macht keine Versprechungen bezüglich des Zugriffs auf Variablen durch die a Zeiger.

Wenn a und b Zeigen Sie auf dasselbe Objekt und ändern Sie es durch a ist legal (vorausgesetzt natürlich, das zugrunde liegende Objekt ist modifizierbar).

Beispiel:

int val = 0;
f(&val, &val);

Während die anderen Antworten die C-Seite erwähnen, lohnt es sich dennoch, einen Blick auf die Rust-Seite zu werfen. Mit Rust ist der Code, den Sie haben, wahrscheinlich dieser:

fn f(a:&mut i32, b:&i32)->bool{
    *a = 2;
    let ret = *b;
    *a = 3;
    return ret != 0;
}

Die Funktion akzeptiert zwei Referenzen, eine änderbar, eine nicht. Referenzen sind Zeiger, die garantiert für Lesevorgänge gültig sind, und veränderliche Referenzen sind ebenfalls garantiert eindeutig, sodass sie optimiert werden

        cmp     dword ptr [rsi], 0
        mov     dword ptr [rdi], 3
        setne   al
        ret

Rust hat jedoch auch rohe Zeiger, die den Zeigern von C entsprechen und keine solchen Garantien geben. Die folgende Funktion, die Rohzeiger annimmt:

unsafe fn g(a:*mut i32, b:*const i32)->bool{
    *a = 2;
    let ret = *b;
    *a = 3;
    return ret != 0;
}

verpasst die Optimierung und kompiliert dazu:

        mov     dword ptr [rdi], 2
        cmp     dword ptr [rsi], 0
        mov     dword ptr [rdi], 3
        setne   al
        ret

Godbolt-Link

Die Funktion dauert a const int* was ein Zeiger auf eine Konstante int ist.

Nein, const int* ist kein Zeiger auf eine Konstante int. Wer das sagt, täuscht sich.

• int* ist ein Zeiger auf ein int, das definitiv nicht konstant ist.

• const int* ist ein Zeiger auf ein Int mit unbekannter Konstanz.

• Es gibt keine Möglichkeit, die Vorstellung eines Zeigers auf ein int auszudrücken, das definitiv eine Konstante ist.

Wenn C eine besser gestaltete Sprache wäre, dann const int * wäre ein Zeiger auf eine Konstante int, mutable int * (entlehnt ein Schlüsselwort aus C++) wäre ein Zeiger auf ein nicht konstantes int, und int * wäre ein Zeiger auf ein Int mit unbekannter Konstanz. Das Weglassen der Qualifizierer (dh etwas über den Typ, auf den gezeigt wird, zu vergessen) wäre ungefährlich – das Gegenteil von echtem C in which hinzufügen das const Qualifikation ist sicher. Ich habe Rust nicht verwendet, aber aus Beispielen in einer anderen Antwort geht hervor, dass es eine solche Syntax verwendet.

Bjarne Stroustrup, der vorstellte constnannte es ursprünglich readonlywas seiner eigentlichen Bedeutung viel näher kommt. int readonly* hätte deutlicher gemacht, dass der Zeiger schreibgeschützt ist, nicht das Objekt, auf das gezeigt wird. Die Umbenennung in const hat Generationen von Programmierern verwirrt.

Wenn ich die Wahl habe, schreibe ich immer foo const*nicht const foo*als das Nächstbeste readonly*.

Es sei darauf hingewiesen, dass es bei dieser Frage um Optimierung geht -Ofast und wie es dort sogar der Fall ist.

Im Wesentlichen kennt der C-Compiler der Funktion nicht den vollständigen diskreten Satz von Adressen, die an ihn übergeben werden könnten, da dieser bis zur Verbindungszeit / Laufzeit nicht bekannt ist, da die Funktion von mehreren Übersetzungseinheiten aufgerufen werden kann, und daher Überlegungen anstellt die jede legale Adresse behandeln, die a und b darauf hindeuten könnte, und das schließt natürlich den Fall ein, in dem sie sich überschneiden.

Daher müssen Sie verwenden restrict um ihm diese Aktualisierung zu sagen a (was die Funktion erlaubt, weil es kein Zeiger auf const ist, aber selbst dann könnte die Funktion const ablegen) aktualisiert den Wert nicht b zeigt auf, was in den Vergleich mit 0 einbezogen werden muss, also das Speichern auf a Dies geschieht, bevor der Vergleich fortgesetzt werden muss, während bei Rust die Standardannahme restriktiv ist. Der Compiler der Funktion weiß das aber *a ist das gleiche wie *(a+1-1) und wird daher keine 2 separaten Geschäfte produzieren, weiß aber nicht, ob a oder b Überlappung.