Ist a^a oder aa undefiniertes Verhalten, wenn a nicht initialisiert ist?

Question 1

Betrachten Sie dieses Programm:

#include <stdio.h>

int main(void)
{
    unsigned int a;
    printf("%u %u\n", a^a, a-a);
    return 0;
}

Ist es undefiniertes Verhalten?

Auf den ersten Blick, a ist eine nicht initialisierte Variable. Das deutet also auf undefiniertes Verhalten hin. Aber a^a und a-a gleich sind 0 für alle Werte von a, denke ich zumindest. Kann man argumentieren, dass das Verhalten wohldefiniert ist?

Question 2

In C11:

Es ist gemäß 6.3.2.1/2 explizit undefiniert, wenn a hat nie seine Adresse genommen (unten zitiert)
Es könnte eine Trap-Darstellung sein (die beim Zugriff UB verursacht). 6.2.6.1/5:

Bestimmte Objektdarstellungen müssen keinen Wert des Objekttyps darstellen.

Unsigned ints können Trap-Darstellungen haben (z. B. wenn es 15 Präzisionsbits und 1 Paritätsbit hat, zugreifen a könnte einen Paritätsfehler verursachen).

6.2.4/6 sagt, dass der Anfangswert ist unbestimmt und die Definition davon unter 3.19.2 ist entweder ein nicht spezifizierter Wert oder eine Trap-Darstellung.

Weiter: in C11 6.3.2.1/2, wie von Pascal Cuoq hervorgehoben:

Wenn der lvalue ein Objekt mit automatischer Speicherdauer bezeichnet, das mit der Registerspeicherklasse hätte deklariert werden können (seine Adresse wurde nie übernommen), und dieses Objekt nicht initialisiert ist (nicht mit einem Initialisierer deklariert und vor der Verwendung keine Zuweisung durchgeführt wurde). ), ist das Verhalten undefiniert.

Dies hat keine Ausnahme für Zeichentypen, daher scheint diese Klausel die vorherige Diskussion zu ersetzen; zugreifen x ist sofort undefiniert, auch wenn keine Trap-Darstellungen existieren. Diese Klausel wurde zu C11 hinzugefügt zur Unterstützung von Itanium-CPUs, die tatsächlich einen Trap-Zustand für Register haben.

Systeme ohne Trap-Darstellungen: Aber was, wenn wir einwerfen &x; sodass der Einwand von 6.3.2.1/2 nicht mehr gilt und wir uns auf einem System befinden, von dem bekannt ist, dass es keine Fallendarstellungen hat? Dann ist der Wert ein unbestimmter Wert. Die Definition von unbestimmter Wert in 3.19.3 ist etwas vage, wird aber durch verdeutlicht DR 451die zu dem Schluss kommt:

Ein nicht initialisierter Wert kann unter den beschriebenen Bedingungen scheinbar seinen Wert ändern.
Jede Operation, die mit unbestimmten Werten ausgeführt wird, hat als Ergebnis einen unbestimmten Wert.

Bibliotheksfunktionen zeigen ein undefiniertes Verhalten, wenn sie für unbestimmte Werte verwendet werden.
Diese Antworten sind für alle Typen geeignet, die keine Trap-Darstellungen haben.

Unter diesem Beschluss int a; &a; int b = a - a; ergibt sich b noch unbestimmten Wert haben.

Beachten Sie, dass wir uns, wenn der unbestimmte Wert nicht an eine Bibliotheksfunktion übergeben wird, immer noch im Bereich des nicht spezifizierten Verhaltens (nicht des undefinierten Verhaltens) befinden. Die Ergebnisse können seltsam sein, z if ( j != j ) foo(); könnte foo rufen, aber die Dämonen müssen in der Nasenhöhle verborgen bleiben.

Question 3

Ja, es ist ein undefiniertes Verhalten.

Erstens kann jede nicht initialisierte Variable eine “kaputte” (auch als “Falle” bezeichnete) Darstellung haben. Selbst ein einziger Versuch, auf diese Repräsentation zuzugreifen, löst undefiniertes Verhalten aus. Darüber hinaus können sogar Objekte von nicht einfangenden Typen (wie unsigned char) können immer noch spezielle plattformabhängige Zustände (wie NaT – Not-A-Thing – auf Itanium) annehmen, die als Manifestation ihres “unbestimmten Wertes” erscheinen könnten.

Zweitens ist nicht garantiert, dass eine nicht initialisierte Variable a hat stabil Wert. Zwei aufeinanderfolgende Zugriffe auf dieselbe nicht initialisierte Variable können vollständig gelesen werden anders Werte, weshalb auch wenn beide zugreift a - a “erfolgreich” sind (kein Trapping), ist das noch nicht garantiert a - a wird zu Null ausgewertet.

Question 4

Wenn ein Objekt eine automatische Speicherdauer hat und seine Adresse nicht verwendet wird, führt der Versuch, es zu lesen, zu undefiniertem Verhalten. Wenn man die Adresse eines solchen Objekts nimmt und Zeiger vom Typ “unsigned char” verwendet, um dessen Bytes auszulesen, garantiert der Standard einen Wert vom Typ “unsigned char”, aber nicht alle Compiler halten sich diesbezüglich an den Standard . ARM GCC 5.1, zum Beispiel, wenn angegeben:

  #include <stdint.h>
  #include <string.h>
  struct q { uint16_t x,y; };
  volatile uint16_t zz;
  int32_t foo(uint32_t x, uint32_t y)
  {
    struct q temp1,temp2;
    temp1.x = 3;
    if (y & 1)
      temp1.y = zz;
    memmove(&temp2,&temp1,sizeof temp1);
    return temp2.y;
  }

generiert Code, der x zurückgibt, wenn y Null ist, selbst wenn x außerhalb des Bereichs 0-65535 liegt. Der Standard stellt klar, dass das Lesen von vorzeichenlosen Zeichen mit unbestimmtem Wert garantiert einen Wert im Bereich von ergibt unsigned charund das Verhalten von memmove ist als Äquivalent zu einer Folge von Lese- und Schreibvorgängen für Zeichen definiert. Daher sollte temp2 einen Wert haben, der über eine Folge von Zeichenschreibvorgängen darin gespeichert werden könnte, aber gcc entscheidet sich dafür, das memmove durch eine Zuweisung zu ersetzen und die Tatsache zu ignorieren, dass der Code die Adressen von temp1 und temp2 verwendet hat.

Eine Möglichkeit zu haben, einen Compiler zu zwingen, eine Variable als einen beliebigen Wert ihres Typs zu betrachten, in Fällen, in denen ein solcher Wert gleichermaßen akzeptabel wäre, wäre hilfreich, aber der Standard gibt kein sauberes Mittel dafür an (außer zum Speichern eines bestimmten Werts, der funktionieren würde, aber oft unnötig langsam ist). Selbst Operationen, die eine Variable logisch dazu zwingen sollten, einen Wert zu halten, der als eine Kombination von Bits darstellbar wäre, können nicht zuverlässig auf allen Compilern funktionieren. Folglich kann für solche Variablen nichts Nützliches garantiert werden.