(Warum) ist die Verwendung einer nicht initialisierten Variablen-Undefinierte Verhalten?

Wenn ich:

unsigned int x;
x -= x;

es ist klar, dass x sollte null nach diesem Ausdruck, aber überall sehe ich, Sie sagen die Verhalten dieser code ist undefiniert, nicht bloß der Wert der x (bis vor der Subtraktion).

Zwei Fragen:

  • Ist die Verhalten dieser code in der Tat undefiniert?

    (E. g. Könnte die code-crash [oder schlechter], die auf einem kompatiblen system?)

  • Wenn dem so ist, warum nicht C sagen, dass die Verhalten ist undefiniert, wenn es ist völlig klar, dass x sollte null sein hier?

    also, Was ist die Vorteil gegeben, indem Sie nicht definieren das Verhalten hier?

Klar, der compiler könnte verwenden Sie einfach was Müll Wert, den es als "handy" in der Variablen, und es funktionieren würde, wie gedacht... was ist falsch mit diesem Ansatz?

  • möglich, Duplikat der Warum macht der C-standard lassen Sie die Verwendung von unbestimmten Variablen undefiniert?
  • Was ist der Vorteil gegeben durch die Festlegung eines speziellen Fall für das Verhalten hier? Sicher, können alle unsere Programme und Bibliotheken, die größer und langsamer, da @Mehrdad vermeiden will, die Initialisierung einer variable in einer bestimmten und seltenen Fall.
  • Wenn man sich die Antwort gibt, es ist die Beantwortung eine etwas andere Frage (warum C nicht zu initialisieren-Variablen), nicht, warum das Verhalten nicht definiert.
  • Ich Stimme nicht mit, dass ein dupe. Unabhängig davon, ob der Wert, den es dauert, die OP erwartet, dass es zu null nach x -= x. Die Frage ist, warum der Zugriff auf nicht initialisierte Werte überhaupt ist UB.
  • Es ist interessant, dass die Aussage x=0; ist in der Regel umgewandelt xor x,x in der Montage. Es ist fast das gleiche wie das, was Sie hier zu tun versuchen, aber mit xor statt der Subtraktion.
  • Es gibt auch Was passiert mit einem erklärt, nicht initialisierte variable, die in C -- hat es einen Wert, dessen akzeptierte Antwort auf jeden Fall funktioniert-Adresse UB.
  • 'also, Was ist der Vorteil von nicht definieren das Verhalten hier? - Ich hätte gedacht, dass der Vorteil der standard-Auflistung nicht die Unendlichkeit der Ausdrücke mit Werten, verlassen Sie sich nicht auf eine oder mehrere Variablen eindeutig ist. Zur gleichen Zeit, @Paul, solche eine änderung der Norm nicht machen würde Programme und Bibliotheken, die alle größer.
  • Ähnlich: stackoverflow.com/questions/25074180/...
  • Sie sollten wahrscheinlich link, das andere für das eine, in Anbetracht dieser kam 2 Jahre früher.
  • OK, habe eine Kommentar-link. Beide Fragen haben guten und etablierten Antworten, damit schließen als Duplikat, ist wohl nicht angebracht, obwohl vielleicht ein moderator machen könnte Zusammenführen.
  • Ja, wir können wohl lassen als Sie ist, Sie sind nicht ganz Duplikate, denke ich.
  • So dass unbestimmte Werte seltsam Verhalten erlauben können nützliche Optimierungen. Zum Beispiel, gegeben uint16_t foo(void) {uint16_t result; , gefolgt von verschiedenen Aussagen, von denen jede möglicherweise oder möglicherweise nicht Ergebnis schreiben und dann return result;} es kann hilfreich sein, um den compiler zu halten result in einer 32-bit-register und dann zurückkehren. Wenn alles speichert einen Wert als Ergebnis, der compiler wird dafür sorgen, den gespeicherten Wert 0..65535, aber wenn es nichts schreibt result ist, halten Sie die return-Wert innerhalb dieses Bereichs würde erfordern das hinzufügen einer extra-Anweisung.
  • Einer Ihrer typischen 4 Jahr später nicht sequiturs. Mein Kommentar war speziell auf das "- Ausdrücke mit den Werten, verlassen Sie sich nicht auf eine oder mehrere Variablen" - in diesem Fall x - x. Die Norm waren, um anzugeben, dass uint16_t foo(void) {uint16_t result; result -= result; return result;} gibt 0 zurück, dies würde nicht konforme Programme und Bibliotheken größer. Wir haben keine Angst vor Buggys code produzieren größere binaries. Wir wollen, dass der compiler optimieren zu können konformen Programme nutzen zu undefiniertem Verhalten, und die Spezifikation nicht ändern würde, dass.

InformationsquelleAutor Mehrdad | 2012-08-14
  1. 83

    Ja, das Verhalten ist undefiniert, aber aus anderen Gründen, als die meisten Menschen bewusst sind.

    Erste ist, ein nicht initialisiertes Wert selbst nicht zu undefiniertem Verhalten, sondern der Wert ist einfach unbestimmt. Der Zugriff auf diese ist dann UB, wenn der Wert geschieht, um eine trap-Darstellung für den Typ. Vorzeichenlose Typen haben selten trap-Repräsentationen, so würden Sie relativ sicher auf dieser Seite.

    Was macht, ist das Verhalten undefiniert ist eine zusätzliche Eigenschaft der Variablen, nämlich, dass es "gewesen sein könnte erklärt mit register" das ist seine Adresse niemals genommen. Solche Variablen werden speziell behandelt, da gibt es Architekturen, die echten CPU-Register, die eine Art von extra-Zustand der "nicht initialisierte" und nicht entsprechen, um einen Wert in den Typ der Domäne.

    Edit: relevanten Begriff der Norm 6.3.2.1p2:

    Wenn der lvalue bezeichnet ein Objekt der automatische Speicher-Dauer
    hätte deklariert mit der register-storage-Klasse (hatte nie
    deren Adresse genommen), und das Objekt ist nicht initialisiert (nicht deklariert
    mit einer Initialisierung und keine Zuweisung zu es durchgeführt wurde, vor
    zu verwenden), ist das Verhalten undefiniert.

    Und deutlicher machen, den folgenden code ist legal unter allen Umständen:

    unsigned char a, b;
memcpy(&a, &b, 1);
a -= a;
    • Hier die Adressen von a und b genommen werden, so ist Ihr Wert nur
      unbestimmt ist.
    • Seit unsigned char nie hat trap-Repräsentationen
      das unbestimmte Wert ist nur nicht angegeben ist, wird jeder Wert von unsigned char könnte
      passieren.
    • Am Ende a muss halten Sie den Wert 0.

    Edit2: a und b haben unspezifische Werte:

    3.19.3 unbekannter Wert

    gültigen Wert des betreffenden Typs, wo diese Internationale Norm enthält keine Anforderungen an die Wert
    gewählt wird in jeder Instanz

    • Bezüglich deinem letzten Punkt: ich verstehe, warum es vernünftig, die a wird 0 aber wie ist das garantiert den standard? Vor der Zuweisung wird der Wert von a ist unbestimmt. Nicht, dass beinhalten, dass zwei Zugriffe könnten unterschiedliche Werte zurückgeben? Oder hat der C-standard garantiert, dass ein unbestimmter Wert gleich bleibt unbestimmt Wert zwischen zwei Zugriffen?
    • Nein, es ist nicht unbestimmt, es ist nicht spezifiziert. Im Grunde bedeutet dies, dass der standard nicht festgelegten besonderen Wert, aber es hat einen gültigen Wert in diesem Bereich, in der Regel entspricht dies nur, um die bit-Muster, das an dieser Adresse. Dieser Wert wird abgezogen von selbst, so dass Ergebnis ist 0.
    • Der standard erfordert das schreiben auf eine variable muss dazu führen, dass alle die unsigned char konstituierenden Teile geschrieben werden, die mit nicht-trap-Werte. Ist es erforderlich, dass Variablen, die nicht geschrieben werden muss, nicht-trap-Formen? Ich würde denken, dass ein compiler auf einer Maschine mit parity-Speicher überprüft (z.B. die original-IBM-PC) erlaubt sein sollte zu füllen undefinierten Speicher mit trap-Werte wurden wenn Sie so geneigt sind, so dass alle Holen würde auslösen einer Falle.
    • ein bestimmtes bit-Muster darstellen kann, eine Falle Wert nur für einen bestimmten Typ hat, und ein regulärer Wert, wenn Sie interpretiert wird als ein anderer Typ. Also ja, unter solchen Architektur, die Sie beschreiben, die einzelnen bytes werden würde nicht fallen, und die Zusammensetzung der alle diese bytes interpretiert als int könnte eine Falle sein. Wenn mit "auslösen der Falle" du meinst "wirft eine Umsetzung definiertes signal", dann ja, eine Implementierung umsetzen konnte int so.
    • Vielleicht bin ich etwas fehlt, aber es scheint mir, dass unsigneds können sicher trap-Repräsentationen. Kannst du zu dem Teil der Norm, die sagt so? Ich sehe in §6.2.6.2/1 das folgende: "Für unsigned integer-Typen andere als unsigned char, die bits der objectrepresentation sind in zwei Gruppen unterteilt werden: Wert bits and padding bits (es muss nicht jeder der letzteren). ... dies soll beknown als der Wert der Repräsentation. Die Werte von padding bits sind nicht spezifiziert. ⁴⁴ ⁾ " Mit dem Kommentar sagen: "⁴⁴⁾ Einige Kombinationen von padding bits generiert möglicherweise trap-Repräsentationen".
    • Fortsetzung mit der Bemerkung: "Einige Kombinationen von padding bits generiert möglicherweise trap-Repräsentationen, zum Beispiel, wenn ein padding-bit ein parity-bit. Unabhängig davon, ist keine arithmetische operation auf gültige Werte erzeugen kann, die eine trap-Darstellung in einer anderen, als Teil einer außergewöhnlichen Situation, wie ein überlauf, und das kann nicht auftreten, mit unsigned-Typen." - Das ist toll einmal wir haben einen gültigen Wert, mit zu arbeiten, aber der unbestimmte Wert könnte eine trap-Darstellung, bevor er initialisiert wurde (z.B. parity-bit falsch gesetzt ist).
    • Sie sind richtig für alle andere Typen als unsigned char, aber diese Antwort ist mit unsigned char. Beachten Sie aber: eine streng konforme Programm berechnen kann sizeof(unsigned) * CHAR_BIT und bestimmen, basierend auf UINT_MAX, dass bestimmten Implementierungen kann unmöglich trap-Repräsentationen für unsigned. Nach diesem Programm hat auch die Entschlossenheit, Sie können dann fortfahren, genau das zu tun, was diese Antwort nicht mit unsigned char.
    • Können Sie erklären, wie ist, dass memcpy definiert in Bezug auf die erste standard-Regel (6.3.2.1p2) du gepostet hast. Ich denke, Ihre Argumentation ist nicht korrekt, weil Sie denken, dass, wenn eine automatische variable ist, seine Adresse tatsächlich genutzt wird, dann ist es ausgenommen von der Regel. Meine Argumentation; auch wenn es die Adresse ist genommen, es hätten noch erklärt wurde, mit register, auch wenn es nicht in diesem Fall, daher ist das Verhalten undefiniert. Die Regel gilt für alle automatischen Objekt: das hätte deklariert mit der register-storage-class. Das bedeutet nicht, dass es sein muss. (Ich hoffe, mein Kommentar war klar.) Gedanken?
    • Ist das nicht die memcpy eine Ablenkung, also wäre das nicht Ihr Beispiel noch gelten, wenn Sie wurden ersetzt durch *&a = *&b;.
    • Ich bin mir nicht mehr sicher. Es gibt eine anhaltende Diskussion über die mailing-Liste der C-Ausschuss, und es scheint, dass dies alles ist ein großes Durcheinander, nämlich eine große Lücke zwischen dem, was ist (oder war) das beabsichtigte Verhalten und dem, was tatsächlich geschrieben. Was ist klar, obwohl, ist, dass der Zugriff auf den Speicher als unsigned char und damit memcpy hilft, den für *& ist weniger klar. Ich werde berichten, sobald diese zur Ruhe kommt.
    • Nur um die Diskussion: blogs.msdn.microsoft.com/oldnewthing/20040119-00/?p=41003. Soweit ich das verstehe, UB übertrumpft alle anderen Garantien, einschließlich der Garantie, dass unsigned char hat keine trap-Darstellung.
    • Ich habe nicht den Eindruck, dass dies viel zu sagen. Zuerst scheint es zu sein, meistens über C++, und das ist sicherlich anders, hier. Und dann diese scheinen MS-Compiler, nicht? Wie gesagt, die Absicht, ausgedrückt durch die C-Ausschuss scheint zu sein, dass access als "Byte" (in beliebiger Charakter-Typen) ist immer definiert Verhalten.
    • Okay. Es ist eine Diskussion über NaT hier, diesem Kommentar deutet darauf hin, dass NaT nicht eine trap-Darstellung. Angesichts Ihrer Forderung, "Zugriff auf [unbestimmten Wert] wird dann UB, wenn der Wert geschieht, um eine trap-Darstellung für den Typ" (meinst du "wenn und nur wenn"?), es scheint ein Widerspruch zu sein. Es gibt ein [verlinkten defect report, was darauf hindeutet, änderungen über unsigned char garantiert.]
    • Also, an alle dies vielleicht noch im Zusammenhang mit dem diskutierten Thema.
    • Die NaT ist ein Zustand, in ein hardware-register. Ich denke, dies ist der Ursprung der Idee von einem Objekt "hätte erklärt mit der register storage class". Sobald Sie Zugriff auf die Daten durch den Speicher als Byte, es können nicht die NaT-Staat, das ist die ganze Idee.
    • Haben Sie zufällig einen link zu der C-Ausschuss mailing-Liste, E-Mail, die Sie erwähnt? (wenn es öffentlich sichtbar)
    • Es gibt Zeiten, wenn Sie nützliche Optimierungen konnten erzielt werden, indem ein Lesen von einem Unbestimmten Wert zu Verhalten in einer Weise, die im Widerspruch zu den definierten Verhalten für Werte dieses Typs, auch für Typen wie uint16_t wo jedes mögliche bit-Muster für das zugrunde liegende storage-würde definiert haben, Verhalten. Wenn solche Dinge nicht-trap-Repräsentationen, was sonst könnte Sie sein?
    • Naja, hängt von der genauen Standard-Formulierung. Wenn der Standard verlangt, dass jede uint16_t Wert ist entweder eine gültige bit-Kombination oder eine trap-Darstellung auch in der Gegenwart nicht definiertes Verhalten, als Sie Recht. Wenn jedoch UB hebt alle anderen Anforderungen, dann kann es alles sein, einschließlich einer Nasen-Dämon Instanz.
    • Wenn Verhalten definiert werden würde, es sei denn, ein lvalue ist zu Lesen, aber das Lesen der lvalue vielleicht Verhalten im Widerspruch zu Ihrem Typ (z.B. ein uint16_t holding 65536), das würde bedeuten, dass der Akt des Lesens den lvalue auslösen würde, UB. Zu mir, das würde wiederum suggerieren, dass die lvalue hielt eine trap-Darstellung.
    • es ist (sic) - Adresse wird genommen, es hätten noch erklärt wurde, mit dem register" -- Nein, er konnte es nicht. Versuchen Sie einfach Lesen, die Teil des Standard zitiert, das spiegelt die Zwänge der & Betreiber: "hätte erklärt mit der register-storage-Klasse (hatte nie seine Adresse genommen)"
    • Zumindest In den Entwurf der C11-standard Annex J. 2 umfasst "den Wert eines Objekts mit automatischer Speicherung-Dauer verwendet wird, während es ist unbestimmt" in die Liste der zu undefiniertem Verhalten. Jetzt ist dieser Anhang ist nicht normativ und es ist nicht klar, dass der Standardisierungsorganisation verpflichtet sich auf die genannten Abschnitte, also vielleicht ist es zu fordern, zu viel in J. 2. Ist das Ihre position? Da ich gelesen habe J. 2, wie zu sagen, dass auch die memcpy Beispiel hätte UB.
    • Nach der Lektüre mehr, die Geschichte noch komplizierter. Die C-Ausschuss-Antwort auf Fehlerbericht #451 (und #260, dort verlinkt) zeigen, dass indeterminite-Werte erlaubt sind, um angezeigt werden zu ändern, ohne direkte Aktionen des Programms. Diese und andere Aussagen im Ausschuss Antwort würde, ich könnte mir vorstellen, dass a -= a würde immer noch zu einer indeterminite Wert, selbst wenn es nicht wahr ist UB. Tun Sie nicht einverstanden sind, und denke, ich bin off base gibt es?
    • In deinem Beispiel wird das Ergebnis nicht spezifiziert, und nicht 0. Siehe: open-std.org/Jtc1/sc22/WG14/www/docs/dr_451.htm Beachten Sie, dass dies gilt auch für unbestimmte Werte.
    • Was ist notwendig, damit die Optimierung ohne Semantik ist eine Anerkennung des nicht-deterministischen Werte und Wege, die Sie zwingt, die teilweise oder vollständig determiniert. Ich finde es bedauerlich, dass, während einige Leute denken, dass, wenn x unbestimmt ist, x & 15 sollten vollständig bestimmt, andere denken, es sollte vollständig unbestimmt. Der ehemalige behindern würde, Optimierungen mehr als nötig, während die letzteren zwingt die Programmierer zu clutter Ihre Quelle mit code-block Optimierungen, die mehr als notwendig. Die Lösung IMHO wäre zu sagen...
    • ...dass eine variable vom Typ X enthält mindestens ein Wert vom Typ X, aber vielleicht halten mehr; wenn x und y beide vom Typ uint32_t, dann (x & y) zulässig wäre, um Rendite jede nicht-leere Teilmenge der Werte gebildet durch Kombinationen der möglichen Werte für x und y ein. Wenn x und y beginnen vollständig unbestimmt ist, dann ist nach "xx = x 3;" xx halten würde, eine oder mehrere von {0,1,2,3} und nach "yy = y & 10;", yy halten würde, eine oder mehrere {0,2,8,10}. Der Ausdruck xx+yy würde dann ergeben Sie eine oder mehrere der {0,1,2,3,4,5,8,9,10,11,12,13}. Während es scheinen mag schwer für Compiler zu verfolgen, die...
    • ...die hauptsächliche nutzen der unbestimmten Werte würde zu ermöglichen-Compiler zu verwenden symbolische substitution neu zu ordnen Operationen, so dass, wenn z.B. ein compiler, die etwas "z=xx+yy;" folgte einige Zeit später durch "w=z"; und später noch von einem anderen "w=z;" es könnte ersetzen die letzteren Zuordnungen mit "w=(x & 3)+(y & 10);". Wenn "x" oder "y" ändert sich unerwartet in Mode, das könnte dazu führen, die beiden Zuordnungen zu speichern verschiedener Werte, aber es würde nicht dazu führen, jeden Wert außerhalb des oben genannten Satzes.
    • in der Tat, unter DR 451, a -= a Ergebnisse in a noch unbestimmt (und nicht nur unspezifisch): unter diesem resultion, den scheinbaren Wert ist unspezifisch bei jeder Beobachtung (aka. "wabbelig")
    • Der Bericht sagt Folgendes: Aus 3.19.2 es folgt, dass, wenn ein Typ hat keine Falle zu Werten, dann unbestimmt und nicht spezifiziert Werte sind die gleichen. Und in 3.19.3, heißt es ausdrücklich, dass ein unbekannter Wert gewählt wird. Was bedeutet, dass der Wert, nachdem er gewählt wurde, nicht mehr ändern. Das ist falsch. Ein unbekannter Wert kann deutlich ändern können, auf irgendwelche 'Beobachtungen': 3.19.3 1 unbekannter Wert gültigen Wert des betreffenden Typs, wo diese Internationale Norm enthält keine Anforderungen auf, welcher Wert gewählt wird, in jedem Fall
    • Die interessantere Frage ist die Wirkung von a=a; a -= a;. Wenn die zweite Anweisung durchgeführt wurden isoliert, die zwei liest a könnten, führen zu unterschiedlichen Werten, da auch nach dem ersten Lesen nichts wäre "set" der Wert von a. Wenn ein Lesen einer Unbestimmten Wert garantiert ist, gibt einen beliebigen Wert, dann nach a=a;, a halten sollte, einige vielleicht unbekannte, aber nicht mehr Unbekannter Wert, also die entfernen-Rendite 0. Leider sind einige Compiler nicht erkennen, in irgendeiner Weise zwingt den compiler, um aus einem "wackligen" - Wert in ein brauchbares ein.
    • können Sie wiederum einen wackeligen geschätzte variable in eine verwendbare man durch die Zuordnung eines nicht-wackelig Wert zu . Es gibt sehr wenig Verwendung für wollen nicht wackelig Müll
    • Für verschiedene sparse-array-und hash-Tabelle-algorithmen machen einen Schlüssel-lookup über uint32_t index = map[key]; if (index < numItems && values[index]=key) ItemFound(...) else ItemNotFound(,,.); Wenn key ist nicht in der Tabelle map[key] zurückkehren konnte beliebiger nicht wackelig uint32_t Wert und code wäre korrekt berichten, dass es nicht gefunden. Wenn index zugewiesen bekommt einen wackligen Wert, obwohl, es gibt keinen Weg, um zu verhindern, dass eine out-of-bounds-array-fetch.
    • das ist, warum ich sagte, "sehr wenig" anstelle von "none at all". Und auf modernen Betriebssystemen gibt es keine Strafe, um damit eine große null initialisiert Zuweisung.
    • C wird Häufig in freistehende Implementierungen, in denen es keine "modernen OS" [oder irgendein OS, für diese Angelegenheit], oder, wenn der Zweck der kompilierte code ist sein das OS.
    • Regel-und embedded-Geräte wäre nicht erforderlich, eine sparse-array so groß, dass die Initialisierung die Zeit ist eine messbare problem. Nicht sagen, dass nie aber es wäre ein sehr seltener Fall.
    • Ich sagte oder, wenn der Zweck der kompilierte code ist werden OS, die reichen können bis zu einige relativ große Systeme. In Fällen, In denen eine "Optimierung" compiler würde einen Programmierer zu zwingen, den computer zu tun, sonst-unnötige Arbeit, der Wert der möglichen Optimierungen können negiert werden, indem die unnötige Arbeit. Ein compiler, der das erreichen könnten 90% der Optimierungen verlangen, während 0% das unnötige Arbeit wäre für effizienteren code.
    • Doch sollte dies nicht Verhalten auftreten, nur für auto-Variablen?

    InformationsquelleAutor Jens Gustedt
  2. 23

    C-standard gibt Compiler eine Menge Spielraum, um Optimierungen durchzuführen. Die Folgen dieser Optimierungen kann überraschend sein, wenn Sie davon ausgehen, eine naive Modell-Programme, wo nicht initialisierte Speicher wird eingestellt, um einige zufällige bit-Muster, und alle Operationen werden durchgeführt in der Reihenfolge, wie Sie geschrieben sind.

    Hinweis: die folgenden Beispiele sind nur gültig, da x hat nie seine Adresse genommen, so ist es "registrieren-wie". Sie würde auch gültig sein, wenn der Typ von x hatte trap-Repräsentationen; dies ist selten der Fall für unsigned-Typen (es muss "verschwenden" mindestens ein bit an Speicher und muss dokumentiert werden), und unmöglich für unsigned char. Wenn x hatte eine signierte geben, dann könnte die Umsetzung definieren Sie die bit-Muster, das ist nicht eine Zahl, die zwischen -(2n-1-1) und 2n-1-1 als eine trap-Darstellung. Sehen Jens Gustedt Antwort.

    Compiler versuchen, zuweisen von Registern zu Variablen, denn Register sind schneller als Speicher. Da das Programm möglicherweise mehr Variablen als der Prozessor verfügt über Register, Compiler führen-register-Allokation, die dazu führt, unterschiedliche Variablen mit demselben register zu verschiedenen Zeiten. Betrachten Sie das Programm-fragment

    unsigned x, y, z;   /* 0 */
y = 0;              /* 1 */
z = 4;              /* 2 */
x = - x;            /* 3 */
y = y + z;          /* 4 */
x = y + 1;          /* 5 */

    Wenn in Zeile 3 ausgewertet wird, x ist noch nicht initialisiert, daher (Gründe der compiler) Zeile 3 muss irgendeine Art von Zufall, dass kann nicht passieren, wegen der anderen Bedingungen, dass der compiler nicht intelligent genug, um herauszufinden. Da z nach der Linie 4 und x ist nicht eingesetzt, bevor die Linie 5, die gleichen register verwendet werden kann für beide Variablen. Also dieses kleine Programm wird kompiliert, um die folgenden Operationen auf Registern:

    r1 = 0;
r0 = 4;
r0 = - r0;
r1 += r0;
r0 = r1;

    Den endgültigen Wert von x ist der Letzte Wert der r0, und der endgültige Wert der y ist der Letzte Wert der r1. Diese Werte sind x = -3 und y = 4, und nicht 5 und 4 wie geschehen würde, wenn x wurde richtig initialisiert.

    Für eine aufwändigere Beispiel betrachten wir das folgende Codefragment:

    unsigned i, x;
for (i = 0; i < 10; i++) {
    x = (condition() ? some_value() : -x);
}

    Angenommen, dass der compiler erkennt, dass condition hat keine Nebenwirkung. Da condition nicht ändern x, der compiler weiß, dass die ersten Durchlaufen der Schleife nicht möglich sein, den Zugriff auf x da es nicht initialisiert, noch nicht. Deshalb ist die erste Ausführung der Schleife ist äquivalent zu x = some_value() gibt es keine Notwendigkeit zum testen der Bedingung. Der compiler kann diesen code kompilieren, als wenn Sie geschrieben hatten

    unsigned i, x;
i = 0; /* if some_value() uses i */
x = some_value();
for (i = 1; i < 10; i++) {
    x = (condition() ? some_value() : -x);
}

    Dem Weg dies kann modelliert werden innerhalb des Compilers ist zu beachten, dass jeder Wert je nach x hat was Wert ist praktisch solange x ist nicht initialisiert. Denn das Verhalten, wenn eine nicht initialisierte variable ist nicht definiert, anstatt die variable lediglich mit einem unbestimmten Wert, den der compiler nicht brauchen, um zu halten verfolgen von jede spezielle mathematische Beziehung zwischen der was-ist-bequem-Werte. Damit der compiler analysieren kann den obigen code in dieser Art:

    • während der ersten Schleife, iteration, x nicht initialisiert ist, durch die Zeit, die -x ausgewertet.
    • -x hat Undefiniertes Verhalten, also sein Wert ist unabhängig-ist-bequem.
    • Die Optimierung der Regel condition ? value : value gilt, so dass dieser code kann vereinfacht werden zu condition; value.

    Konfrontiert mit den code in deiner Frage, diese gleichen compiler analysiert, dass, wenn x = - x wird ausgewertet, der Wert von -x ist, was-ist-bequem. So kann die Zuweisung optimiert werden entfernt.

    Habe ich noch nicht geschaut ein Beispiel für einen compiler, der sich so verhält, wie oben beschrieben, aber es ist die Art von Optimierung guter Compiler zu tun versuchen. Ich wäre nicht überrascht zu begegnen. Hier ist eine weniger plausible Beispiel eines Compilers, mit dem dein Programm stürzt ab. (Es kann nicht sein, dass man unglaubwürdig, wenn Sie, kompilieren Sie Ihr Programm in eine Art erweiterte debugging-Modus).

    Diese hypothetische compiler ordnet jede variable in einem anderen Speicher Seite und stellt die Seite Attribute so, dass das Lesen von eine nicht initialisierte variable bewirkt, dass ein Prozessor Falle aufruft, die ein debugger. Jede Zuordnung zu einer variable macht Sie sicher, dass der memory-Seite zugeordnet ist normal. Dieser compiler nicht versuchen, führen Sie eine erweiterte Optimierung — es ist in einem debugging-Modus, soll zum Auffinden von bugs wie nicht initialisierten Variablen. Wenn x = - x ausgewertet wird, der rechten Seite bewirkt, dass eine Falle, und der debugger startet.

    • +1 Schöne Erklärung, die standard ist, nehmen spezielle Pflege, die situation. Für eine Fortsetzung dieser Geschichte, siehe meine Antwort unten. (zu lange, als Kommentar).
    • Oh, deine Antwort macht einen sehr wichtigen Punkt, den ich (und andere) übersehen: es sei denn, der Typ hat trap-Werte, die für einen unsigned-Typ erfordert "verschwenden" mindestens ein bit x hat einen nicht initialisierten Wert, sondern das Verhalten über den Zugang definiert werden würde, wenn x nicht registrieren müssen-wie Verhalten.
    • zumindest Klang macht die Art der Optimierungen, die Sie erwähnt: (1), (2), (3).
    • Welche praktischen Vorteil gibt es mit clang-Prozess Dinge in die Mode? Wenn downstream-code nie verwendet, den Wert der x, dann werden alle Operationen auf Sie könnte verzichtet werden, ob der Wert definiert war oder nicht. Wenn folgender code z.B. if (volatile1) x=volatile2; ... x = (x+volatile3) & 255; wäre genauso glücklich mit einem Wert zwischen 0 und 255, die x enthalten könnte, in dem Fall, wo volatile1 hatte, ergab null, ich würde denken, dass eine Umsetzung erlauben würde, dass die Programmierer das weglassen einer unnötigen schreiben x angesehen werden sollte, da höhere Qualität, als ein Verhalten würde...
    • ...in völlig unvorhersehbare Weise in diesem Fall. Eine Umsetzung, die würde zuverlässig erhöhen, eine von der Implementierung definierte Falle, in diesem Falle kann, für bestimmte Zwecke angesehen werden als von höherer Qualität, aber Verhalten sich völlig unvorhersehbar scheint mir, wie die niedrigste Qualität, die form des Verhaltens, die für so ziemlich jeden Zweck.
    InformationsquelleAutor Gilles 'SO- stop being evil'
  3. 16

    Ja, das Programm Abstürzen. Es könnte zum Beispiel sein trap-Repräsentationen (bestimmtes bit-Muster, die nicht behandelt werden kann), die möglicherweise die Ursache für CPU-interrupt, der nicht behandelte, konnte das Programm zum Absturz bringen.

    (6.2.6.1 an einem späten C11 Entwurf sagt)
    Bestimmte Darstellungen von Objekten müssen nicht die einen Wert darstellen von der
    Objekt-Typ. Wenn der gespeicherte Wert eines Objekts hat eine solche
    Darstellung und ist zu Lesen von einem lvalue-Ausdruck, der keine
    Charakter-Typ, ist das Verhalten undefiniert. Wenn so eine Darstellung ist
    entsteht durch einen Nebeneffekt, das ändert die gesamte oder ein Teil des Objekts
    durch eine lvalue-Ausdruck, der keinen Charakter geben, der
    das Verhalten ist undefiniert.50) eine Solche Darstellung wird als "überfüllung" bezeichnet
    Darstellung.

    (Diese Erklärung gilt nur auf den Plattformen, wo unsigned int können trap-Repräsentationen, die selten ist, auf die echten Systeme; siehe Kommentar für Informationen und Verweise zu alternativen und vielleicht weitere häufige Ursachen, die dazu führen, den standard der aktuellen Formulierung.)

    • Können geben Sie mindestens ein Beispiel für ein bit-Muster für eine ganze Zahl, Laufwerk, CPU-verrückt?
    • NaNs mit Schwimmern in den Sinn kommen. NaN - NaN == NaN, nicht null ist.
    • Dies ist etwa C, nicht bestimmten CPUs. Jeder kann trivial design einer CPU, die bit-Muster für ganze zahlen, die Sie fahren verrückt. Betrachten Sie eine CPU, die hat eine "crazy bit" in den Registern.
    • hängt von der CPU. Es gibt keine für Ganzzahlen auf x86.
    • So kann ich also sagen, das Verhalten ist klar definiert, im Falle von Integer-zahlen und x86?
    • Gut, wenn es nicht definiert, dann nicht-es sei denn dein compiler speziell sagt es ist definiert, man kann nicht davon ausgehen, es ist definiert, denn man kann nicht annehmen, dass der compiler veranlasst den Anweisungen, die Sie erwarten (es wird sich wahrscheinlich vermeiden, so zu tun, für die Optimierung).
    • Gut, theoretisch könnte man einen compiler, die beschlossen, nur 28-bit-Ganzzahlen (auf x86), und fügen Sie spezifischen code zu behandeln jede addition, der Multiplikation (ein so weiter) und stellen Sie sicher, dass diese 4 bits ungenutzt bleiben (oder emittieren ein SIGSEGV sonst). Ein uninitalized Wert, könnte dies dazu führen,.
    • Ich hasse es, wenn jemand Beleidigungen jeder andere auch, weil das jemand nicht verstehen, das Problem. Ob das Verhalten nicht definiert ist ausschließlich eine Frage dessen, was der standard sagt. Oh, und es gibt nichts, praktisch alle über eq ' s Szenario ... es ist völlig künstlich.
    • P. S. David Schwartz die Idee, unter die andere Antwort ist eine praktische Idee und schlägt eine andere ... angenommen, dass der physische Speicher nicht zugeordnet virtuellen Adressen bis initialisiert oder geschrieben; dann Zugriff auf eine nicht initialisierte variable kann zu einer Zugriffsverletzung.
    • Lazarenko: Itanium-CPUs haben eine NaT (not a Thing) flag für jede Ganzzahl-register. Die NaT-Flag wird verwendet, um die Kontrolle spekulative Ausführung und kann Verweilen in Registern, die nicht richtig initialisiert ist, bevor Nutzung. Das Lesen aus einem solchen register mit einem NaT-bit gesetzt ergibt eine Ausnahme. Siehe blogs.msdn.com/b/oldnewthing/archive/2004/01/19/60162.aspx
    • Diese Erklärung ist unzureichend, es wird nur gesagt, die Hälfte der Geschichte für den Fall, dass der Wert geschieht, um eine trap-Darstellung. Noch ist UB von der Norm, aber aus einem anderen Grund. Bitte siehe meine Antwort.
    • Sie sind einfach nicht gegeben, das gute Gründe. In diesem Fall die UB hat nichts zu tun mit den trap-Repräsentationen. Es kommt von der Tatsache, dass die Adresse der variable wird nie genommen. So, ich nehme es zurück, Sie werden nicht sagen Hälfte die Geschichte, die Sie erzählt die falsche Geschichte.
    • zu viel real-Welt-denken verdirbt gute theoretische Probleme 🙁
    • wahrscheinlich ist mein Englisch nicht gut genug, um zu erfassen, was Sie zu sagen versuchen. Dies ist nicht ein theoretisches Problem. Unspezifische Werte, die verwendet werden können, unter gewissen Umständen, in meiner Antwort, die ich gegeben habe, gültigen code für, die.
    • mein Beispiel scheint es, ist mehr eine theoretische Frage für alle aber die theoretische Implementierungen von unsigned integer-Typen.
    • Diese Antwort ist falsch, wo es heißt: "und ja, das Verhalten ist in der Tat nicht definiert." Wie die Antworten von mir und Jens Gustedt-show (mit Zitaten aus den C-standard, die diese Antwort nicht geben), wobei der Wert einer nicht initialisierten Objekt nicht von selbst verursachen, nicht initialisierte Verhalten. In C-1999, undefinierten Verhalten tritt nur auf, wenn bestimmte andere Voraussetzungen erfüllt sind, und diese Bedingungen nicht erfüllt sind, die für integer-Typen, die auf den meisten gängigen Systemen. Siehe Jens Gustedt Antwort für die C-2011-situation.
    • Es ist nicht ungewöhnlich für nicht initialisierte Variablen zu Verhalten, als ob Sie Werte, die außerhalb des Bereichs Ihrer Art sind. IMHO, es sollte eine Kategorie von Verhalten, die auf solche Dinge, die wären-im Gegensatz zu der Implementierung Definierte Verhalten--nicht erforderlich, eine Implementierung zu definieren, was passieren würde, im detail, aber-im Gegensatz zu UB--würde nicht gewähren Compiler unbegrenzten Spielraum, um entweder.

    InformationsquelleAutor eq-
  4. 13

    (Diese Antwort-Adressen, C 1999. Für C 2011, siehe Jens Gustedt Antwort.)

    C-standard nicht sagen, der Wert eines Objekts, der die automatische Speicherung Dauer, die nicht initialisiert ist Undefiniertes Verhalten. Die C 1999 standard sagt, in 6.7.8 10, "Wenn ein Objekt hat automatische Speicherdauer ist nicht explizit initialisiert, ist Ihr Wert unbestimmt." (Dieser Absatz geht auf um zu definieren, wie statische Objekte werden initialisiert, so dass die nur auf nicht initialisierte Objekte, die wir besorgt sind, sind automatische Objekte).

    3.17.2 definiert "unbestimmte Wert" als "entweder eine unbestimmte Zahl oder eine trap-Darstellung". 3.17.3 definiert "unbekannter Wert" als "gültig" den Wert der betreffenden Art, wo diese Internationale Norm enthält keine Anforderungen auf, welcher Wert gewählt wird, in jedem Fall".

    Also, wenn das nicht initialisierte unsigned int x verfügt über einen unbestimmten Wert, dann x -= x produzieren muss null. Damit bleibt die Frage, ob es möglicherweise eine Falle sein Darstellung. Zugriff auf eine Falle Wert verursacht Undefiniertes Verhalten, pro 6.2.6.1 5.

    Einige Arten von Objekten, die möglicherweise trap-Repräsentationen, wie der signaling-NaNs der floating-point-zahlen. Aber unsigned-Ganzzahlen sind spezielle. Pro 6.2.6.2, die jeweils den Wert N bits eines unsigned int stellt eine Potenz von 2 ist, und jede Kombination von Wert-bits steht für einen der Werte von 0 bis 2N-1. Also vorzeichenlose Ganzzahlen können trap-Repräsentationen, die nur durch einige Werte in Ihrem padding-bits (wie ein parity-bit).

    Wenn auf der Ziel-Plattform, ein unsigned int hat keine Polsterung-bits, dann wird eine nicht initialisierte unsigned int kann nicht eine trap-Darstellung, und über Ihren Wert nicht der schaltplanbearbeitung zu undefiniertem Verhalten.

    • Wenn x hat eine trap-Darstellung, dann x -= x könnte trap, nicht wahr? Trotzdem, +1 für den Hinweis auf vorzeichenlose Ganzzahlen mit keine zusätzlichen bits müssen definierte Verhalten -- es ist eindeutig das Gegenteil von den anderen Antworten und (nach dem Zitat) es scheint das zu sein, was der standard bedeutet.
    • Ja, wenn der Typ x hat eine trap-Darstellung, dann x -= x könnte Falle. Auch einfach x als könnte der Wert trap. (Es ist sicher zu bedienen x als lvalue; schreiben in ein Objekt nicht beeinflusst werden durch eine trap-Darstellung, die in es.)
    • vorzeichenlose Typen haben selten eine trap-Darstellung
    • Zitiert Raymond Chen", Auf die ia64, jede 64-bit-register ist eigentlich 65 bits. Das zusätzliche bit wird als "NaT", das steht für "kein Ding". Das bit wird gesetzt, wenn das register nicht einen gültigen Wert enthält. Betrachten Sie es als die integer-version des floating-point-NaN. ... wenn Sie ein register, dessen Wert auf NaT und Sie so viel wie atmen Sie in die falsche Richtung (zum Beispiel, versuchen zu retten, deren Wert zum Speicher), der Prozessor wird zu erhöhen eine STATUS_REG_NAT_CONSUMPTION Ausnahme". I. e., eine trap-bit kann komplett außerhalb der Wert.
    • -1 mit Der Aussage "Wenn auf der Ziel-Plattform, ein unsigned int hat keine Polsterung-bits, dann wird eine nicht initialisierte unsigned int kann nicht eine trap-Darstellung, und über Ihren Wert nicht der schaltplanbearbeitung zu undefiniertem Verhalten." nicht berücksichtigt-Programme wie die x64 NaT-bits.
    • Auch auf der herkömmlichen 32-bit-Rechner, wäre es nicht ungewöhnlich, dass eine nicht initialisierte variable des Typs uint16_t Wert außerhalb Bereich 0..65535, und für die Funktion der return-Typ uint16_t, dass die Erträge, die Variablen zu übergeben, deren Wert durch den Anrufer ohne Maskierung.
    • ist eine exakte Breite geben. Und der C++ - standard erlaubt nur den Baum möglichst Wert-Kodierungen, die für 16 bit nicht produzieren "einen Wert außerhalb des Bereichs 0..65535", die Sie behaupten, ist "nicht ungewöhnlich". I. e. du bist einfach nur falsch. Das problem ist nicht die überschreitung der Wertebereich und in der Praxis auch nicht-trap-Repräsentationen, aber möglichst zusätzliche Informationen über den Wert oder vielmehr über den Mangel an einem angegebenen Wert.
    • Ich habe gesehen, eine Reihe von Compilern, darunter gcc ARM Compiler, code zu erzeugen, wo Registern zugeteilt auf nicht initialisierte Variablen halten kann beliebige Werte die brauchen, passen nicht zu den Variablen " Bereich. E. g. ARM-gcc 4.8.2 gegeben uint16_t foo(uint32_t x, uint32_t y, uint32_t z) { uint16_t q; if (x) q=x; return q; } generiert code, die, wenn aufgerufen, von außen code, werden wieder alle 32 bits von z, wenn x ist null.
    • Wenn die Verwendung solcher Variablen ist UB solcher code ist konform. Wenn es nicht ist, solchen code möglicherweise oder möglicherweise nicht konform, aber es ist schon alltäglich Verhalten für eine lange Zeit, und es ermöglicht einen effizienteren code als Sie sonst möglich wären [wenn im obigen Fall die gcc erzeugt unnötig ineffizienten code].
    • Ich sehe, was du meinst, die bits, die außerhalb der variable beeinflusst werden kann. Und wenn z.B. das Ergebnis von foo() wird umgewandelt in 32 bit unter der Annahme, dass die höheren bits der 32-bit-Position null sind, dann Hoppla. So ist es ein echtes problem, dass ich nicht denke der.
    • Ich denke, den Standard, bei Verwendung von Unbestimmten Wert als in der UB, weil das ist einfacher als zu versuchen, alles zu beschreiben, was passieren kann, aber ich denke, dass ist sehr schade, denn es gibt viele Fälle, in denen code "geht durch" Werte, die möglicherweise oder möglicherweise nicht sinnvoll, die an Empfänger, die möglicherweise oder möglicherweise nicht verwenden (aber wer nicht, wenn Sie nicht aussagekräftig sind), und machen rvalue Umwandlung von Unbestimmten Werte aufrufen zu Undefiniertem Verhalten macht es notwendig, hinzufügen von code, um sicherzustellen, dass die Unbestimmten Werte kann nicht durch geführt.
    • Ich würde gerne sehen, die Standard erkennen das Konzept von Speicherplätzen im Besitz einer non-deterministischen union der Werte, so dass Operationen, die weichen müssen ein konkretes Ergebnis (z.B. eine "if" - test) Verhalten können, als wenn der Speicherort statt jeder Wert halten könnte, und die anderen Operationen (wie "+") kann die Ausbeute eines nicht-deterministischen union aller Werte, hätte nachgegeben, indem Sie source-Operanden.

    InformationsquelleAutor Eric Postpischil
  5. 11

    Ja, es ist undefiniert. Der code kann zum Absturz führen. C sagt, das Verhalten ist undefiniert, weil es gibt keinen bestimmten Grund, um eine Ausnahme von der Allgemeinen Regel. Der Vorteil ist der gleiche Vorteil wie alle anderen Fälle von Undefiniertes Verhalten -- der compiler nicht zur Ausgabe spezieller code, um diese Arbeit zu machen.

    Klar, der compiler könnte einfach verwenden, was Müll Wert, den es als "handy" in der Variablen, und es funktionieren würde, wie gedacht... was ist falsch mit diesem Ansatz?

    Warum denkst du, dass das nicht passiert? Das ist genau der Ansatz. Der compiler ist nicht erforderlich, damit es funktioniert, aber es ist nicht erforderlich, um es scheitern.

    • Der compiler muss kein spezieller code für diese entweder, wenn. Einfach die Zuweisung des Speicherplatzes (wie immer) und nicht letzteres die variable gibt es das richtige Verhalten. Ich glaube nicht, dass Besondere Logik.
    • Das ist völlig falsch. Betrachten Sie zwei Fälle: 1) Floating-point-zahlen, die Darstellungen, die nicht null zurückgeben, wenn subtrahiert, die sich wie NaNs. 2) Hardware, die leckereien nicht initialisierten Speicher speziell. (In jedem Fall, das ist kein problem. Wenn Sie denken, dass keine speziellen code benötigt wird, dann große. Der standard erfordert keine. So perfekt. Wenn jeder ist erforderlich, wenn der standard nicht erforderlich ist, den compiler zu tun.)
    • (1) könnten Sie haben gerade gesagt, die Implementierung festgelegt, oder vielleicht benötigt es für die (unsignierte?) Integrale Typen, da es nicht ohne zusätzliche Arbeit zu "lassen Sie den Inhalt als-ist" sowieso. (2) Hmm... ich bin mir nicht sicher, ich weiß, was du meinst. Wie, wie würden Sie behandeln nicht initialisierten Speicher speziell, und warum könnte das sinnvoll sein?
    • 1) Sicher, Sie haben könnte. Aber ich kann nicht glauben, kein argument, das würde besser. 2) Die Plattform weiß, dass der Wert nicht initialisierter Speicher kann nicht entgegengehalten werden, so ist es frei, es zu ändern. Zum Beispiel kann es zu null-initialisierten Speicher im hintergrund zu haben genullt Seiten bereit für den Einsatz, wenn nötig. (Berücksichtigen Sie, dass, wenn dies geschieht: 1) Wir Lesen den Wert zu subtrahieren, zu sagen, wir Holen 3. 2) Die Seite wird unwiderruflich gelöscht werden, weil es nicht initialisiert, ändern Sie den Wert auf 0. 3) Wir machen eine Atomare subtrahieren, die Aufteilung der Seite und machen den Wert -3. Oops.)
    • Oooooh, sehr interessant! Das macht sehr viel Sinn, danke! 🙂
    • Beachten Sie, dass auch unsigned Typen haben darf, padding-bits und so-trap-Repräsentationen.
    • Etwas, was wichtig zu Bedenken ist aber, dass diejenigen, die entworfen, der standard wahrscheinlich nicht von einem bestimmten Szenario in den Sinn. Sie konnte nur erahnen, was in Zukunft Computer-und hardware wäre, wie und konnte sich nicht zuverlässig Vorhersagen, welche Auswirkungen Ihre Entscheidungen haben. So dass Sie nur erforderliche Verhalten, dass Sie das Gefühl, gebraucht zu verlangen, damit die Menschen zu bauen, die richtigen Programme, und Sie betrachtet jede Anforderung ein Potenzial, Kosten zu rechtfertigen profitieren. Dass ein vorhersagbares Verhalten für nicht initialisierte Daten fehlgeschlagen, der test Ihrer Meinung nach.
    • bitte fügen Sie Ihrem Beispiel, um die Antwort --- es ist eines der besten, die ich gesehen habe.
    • -1 da gibst du keine Begründung für deine Behauptung an alle. Es gibt Situationen, in denen Sie gelten würden, zu erwarten, dass der compiler nimmt einfach den Wert, der geschrieben wird, in den Speicher.
    • Ich verstehe nicht, Ihren Kommentar. Können Sie bitte klären?
    • Weil Sie nur behaupten, dass es eine Allgemeine Regel, ohne sich auf es. Als solches ist es nur ein Versuch der "Beweis durch Autorität", das ist nicht das, was ich erwarten, dass auf SO. Und für nicht effektiv argumentieren, warum dies nicht so sein, ein unspezifischer Wert. Der einzige Grund, dass dies UB im Allgemeinen Fall ist, dass x könnte deklariert werden als register, das ist, dass seine Adresse nie genommen. Ich weiß nicht, ob Sie sich dessen bewusst waren (wenn Sie versteckt hatten, ist es effektiv), aber eine richtige Antwort muss es erwähnen.
    • Diese Antwort ist falsch, wo es heißt: "ja, es ist undefiniert." Wie die Antworten von mir und Jens Gustedt-show (mit Zitaten aus den C-standard, die diese Antwort nicht geben), wobei der Wert einer nicht initialisierten Objekt nicht von selbst verursachen, nicht initialisierte Verhalten. In C-1999, undefinierten Verhalten tritt nur auf, wenn bestimmte andere Voraussetzungen erfüllt sind, und diese Bedingungen nicht erfüllt sind, die für integer-Typen, die auf den meisten gängigen Systemen. Siehe Jens Gustedt Antwort für die C-2011-situation.
    • Auf viele real-Compiler für 32-bit-Maschinen, eine nicht initialisierte variable vom Typ uint16_t halten können Werte außerhalb des range 0-65535. Wie wäre das zulässig, wenn solche Werte wurden nicht als trap-Repräsentationen?

    InformationsquelleAutor David Schwartz
  6. 6

    Für jede variable eines beliebigen Typs, die nicht initialisiert ist oder aus anderen Gründen besitzt einen unbestimmten Wert, das gilt für die code-Lesung Wert:

    • Im Fall der variable hat automatische Speicherdauer und nicht seine Adresse genommen, der code ruft immer Undefiniertes Verhalten [1].
    • Ansonsten, falls das system unterstützt die trap-Repräsentationen für die gegebene variable-Typ, der code ruft immer Undefiniertes Verhalten [2].

    • Sonst, wenn es keine trap-Repräsentationen, nimmt die variable einen unbestimmten Wert. Es gibt keine Garantie, dass dieser unspezifische Wert stimmt jedes mal, wenn die variable gelesen wird. Jedoch, es ist garantiert eine Falle Vertretung und deshalb ist es garantiert nicht aufrufen Undefiniertes Verhalten [3].

      Den Wert kann man dann sicher verwendet werden, ohne dass ein Programm-Absturz, obwohl ein solcher code ist nicht portabel zu Systemen mit trap-Repräsentationen.

    [1]: C11 6.3.2.1:

    Wenn der lvalue bezeichnet eine
    Gegenstand des automatic storage duration, die hätte deklariert mit der register
    storage class (nie seine Adresse genommen), und das Objekt ist nicht initialisiert (nicht deklariert
    mit einer Initialisierung und keine Zuweisung zu es durchgeführt wurde, vor der Verwendung), das Verhalten
    nicht definiert ist.

    [2]: C11 6.2.6.1:

    Bestimmte Darstellungen von Objekten müssen nicht repräsentieren einen Wert von dem Typ des Objekts. Wenn die gespeicherte
    Wert eines Objekts hat solch eine Darstellung und zu Lesen von einem lvalue-Ausdruck, der das tut
    keine Zeichen geben, ist das Verhalten undefiniert. Wenn eine solche Darstellung erzeugt wird
    durch eine Nebenwirkung, die ändert die gesamte oder ein Teil des Objekts durch ein lvalue-Ausdruck, der
    keine Zeichen geben, ist das Verhalten undefiniert.50) eine Solche Darstellung nennt
    eine trap-Darstellung.

    [3] C11:

    3.19.2

    unbestimmten Wert

    entweder eine unbestimmte Zahl oder eine trap-Darstellung

    3.19.3

    unbekannter Wert

    gültigen Wert des betreffenden Typs, wo diese Internationale Norm enthält keine
    Anforderungen an, welcher Wert ausgewählt wird in jeder Instanz

    HINWEIS: Ein unbekannter Wert nicht eine trap-Darstellung.

    3.19.4

    trap Darstellung

    ein Objekt der Repräsentation, die nicht brauchen, die einen Wert darstellen von der Objekt-Typ

    • Ich würde behaupten, das wird zu "Es ist immer Undefiniertes Verhalten", wie C die abstrakte Maschine -können - haben-trap-Repräsentationen. Nur weil Ihr die Umsetzung nicht, verwenden Sie nicht den code definiert. In der Tat eine strenge Lesen würde auch nicht darauf bestehen, die trap-Repräsentationen werden in der hardware aus, was ich nicht sagen, ich sehe nicht ein, warum ein compiler konnte sich nicht entscheiden, ein bestimmtes bit-Muster ist eine Falle, überprüfen Sie dies jedes mal, wenn die variable gelesen wird, und rufen Sie die UB.
    • Beachten Sie, dass möglicherweise unsigned char ist ausgenommen von dieser aus obigen Gründen.
    • In der realen Welt, von 99,9999% aller Computer sind Zweierkomplement CPUs ohne trap-Repräsentationen. Daher keine Falle ist die Vertretung der norm und diskutieren über das Verhalten auf diese realen Computern ist hoch relevant. Davon ausgehen, dass Wild exotischen Computern ist die norm, ist nicht hilfreich. Trap-Repräsentationen in der realen Welt sind so selten, dass die Präsenz der Begriff trap Darstellung in der standard wird meist als ein standard-defekt geerbt aus den 1980er Jahren. Wie ist die Unterstützung für das Einerkomplement und-Zeichen & Größenordnung Computer.
    • Übrigens, dies ist ein guter Grund, warum stdint.h sollte immer verwendet werden, statt der nativen Typen von C. Wegen stdint.h erzwingt die 2-Komplement-und no padding bits. In anderen Worten, die stdint.h Typen sind nicht erlaubt, werden voll der Mist.
    • Wieder der Ausschuss Reaktion auf den Mangel Bericht sagt, dass: "Die Antwort auf Frage 2 ist, dass jede operation, die auf unbestimmte Werte haben einen unbestimmten Wert als Ergebnis." und "Der Antwort auf Frage 3 ist, die library-Funktionen werden in der Ausstellung zu undefiniertem Verhalten, wenn verwendet, auf unbestimmte Werte."
    • DRs 451 und 260
    • Ja, ich weiß, dass DR. Es nicht im Widerspruch zu dieser Antwort. Erhalten Sie möglicherweise einen unbestimmten Wert beim Lesen von nicht-initialisierten Speicher und es ist nicht unbedingt der gleiche Wert jedes mal. Aber das ist nicht spezifiziert Verhalten, nicht undefined Verhalten.
    • Detail auf <stdint.h>. Das optionale Exact-width integer types kein padding-bits, und ein Zweierkomplement-Darstellung. Der header hat auch erforderlich Minimum-Breite integer-Typen und Schnellste minimum-Breite integer-Typen nicht angegeben, werden keine Polsterung-bits, und ein Zweierkomplement-Darstellung.
    • Die Autoren des Standards erwarten, dass Menschen, die Qualität produzieren Implementierungen von versuchen zur Unterstützung von Verhaltens-garantiert über diesen Auftrag durch die Norm in Fällen, in denen die Nutzer profitieren würden, übersteigen die Kosten. Für viele Implementierungen' beabsichtigten Zwecke, es würde nützlich sein, und die Kosten fast nichts, um zu garantieren, dass, wenn die bytes, die ein Objekt halten, Unbestimmte Werte, die jeder Lesen der Objekt verhält sich, als ob die bytes im schlimmsten Fall statt einer (möglicherweise unterschiedlichen) Unbekannter Wert. Das kann nicht wahr sein, der alle Implementierungen jedoch.
    • Der DR. sagt, dass die Implementierungen sind nicht erforderlich bieten solche Garantien, die in der Standardeinstellung stellt die Frage, ob Sie zu unterstützen, zu einer Qualität der Umsetzung Problem. Weder Implementierungen für Zwecke, die nicht vereinbar wäre mit solchen Garantien noch Müll-Qualität-aber-konformen Implementierungen, sollte erwartet werden, zu wahren, solche Garantien, aber der Standard schweigt auf die Frage, ob die general-purpose-Implementierungen, die nicht erkannt werden sollten, als von minderer Qualität. Ich denke, Sie sollten, aber das ist eine Frage der Urteil.

    InformationsquelleAutor Lundin
  7. 2

    Während viele der Antworten konzentrieren sich auf Prozessoren, die Falle auf nicht initialisierte-register Zugriff, skurrile Verhaltensweisen, die entstehen können, sogar auf Plattformen, die keine solchen fallen, mit Compilern, die keine Besondere Anstrengung zu nutzen UB. Betrachten Sie den code:

    volatile uint32_t a,b;
uin16_t moo(uint32_t x, uint16_t y, uint32_t z)
{
  uint16_t temp;
  if (a)
    temp = y;
  else if (b)
    temp = z;
  return temp;  
}

    einen compiler für eine Plattform wie den ARM, wo Sie alle Anweisungen anderen als
    Lasten und Geschäfte betreiben, die auf 32-bit-Register vernünftigerweise Prozess der
    code Sie in einer Weise entspricht:

    volatile uint32_t a,b;
//Note: y is known to be 0..65535
//x, y, and z are received in 32-bit registers r0, r1, r2
uin32_t moo(uint32_t x, uint32_t y, uint32_t z)
{
  //Since x is never used past this point, and since the return value
  //will need to be in r0, a compiler could map temp to r0
  uint32_t temp;
  if (a)
    temp = y;
  else if (b)
    temp = z & 0xFFFF;
  return temp;  
}

    Wenn entweder flüchtig liest sich die Ausbeute eines nicht-null-Wert, r0 geladen wird mit einem Wert im Bereich von 0...65535. Sonst wird es Ausbeute, was auch immer es stattfindet, wenn die Funktion aufgerufen wurde (d.h. der übergebene Wert in x), die möglicherweise nicht ein Wert im Bereich 0..65535. Der Standard fehlt jede Terminologie zu beschreiben, das Verhalten von Wert, dessen Typ uint16_t, aber deren Wert ist außerhalb des Bereichs von 0..65535, außer zu sagen, dass jede Handlung, die produzieren könnte ein solches Verhalten ruft UB.

    • Interessant. Du sagst also die akzeptierte Antwort ist falsch? Oder werden Sie sagen, es ist richtig, in der Theorie, sondern in der Praxis-Compiler können das tun seltsamer Dinge?
    • Es ist üblich, für die Implementierungen zu haben, Verhalten, das sich jenseits der Grenzen dessen, was möglich wäre, in der Abwesenheit von UB. Ich denke, es wäre hilfreich, wenn die Standard-anerkannt das Konzept einer teilweise unbestimmten Wert, dessen "zugewiesen" bits Verhalten in ein Mode, das ist am schlimmsten, nicht spezifiziert, aber mit zusätzlichen oberen bits, die Verhalten sich nicht-deterministisch (z.B. wenn das Ergebnis der obigen Funktion wird gespeichert, um eine variable vom Typ uint16_t, dass die variable vielleicht mal Lesen, wie 123 und manchmal 6553623). Wenn das Ergebnis ignoriert wird...
    • ...oder in einer Weise verwendet, dass jede mögliche Weise, es könnte gelesen werden würde, alle Ausbeute endgültige Ergebnisse, Erfüllung der Anforderungen, die Existenz der teilweise unbestimmten Wert sollte nicht das problem sein. Auf der anderen Seite, es gibt nichts in der Norm würde es ermöglichen, die für die Existenz der teilweise unbestimmten Werte in allen Fällen, in denen der Standard verlangen würde, jede Verhaltens-oder Anforderungen erfüllt.
    • Es scheint mir, dass das, was Sie beschreiben, ist genau das, was in der akzeptierten Antwort -, dass, wenn eine variable könnte erklärt wurden, mit register, dann kann es zusätzliche bits, die das Verhalten potenziell nicht definiert. Das ist genau das, was du sagst, richtig?
    • Die akzeptierte Antwort konzentriert sich auf Architekturen, auf deren Register haben eine extra "nicht initialisierte" Zustand, und trap, wenn eine nicht initialisierte register geladen wird. Solche Architekturen existieren, aber sind nicht üblich. Ich beschreibe ein Szenario, in dem alltäglich hardware-Verhalten aufweisen können, die außerhalb des Einflussbereichs von etwas betrachtet durch den C-Standard, wäre aber sinnvoll eingeschränkt, wenn ein compiler dies nicht eine eigene zusätzliche Verrücktheit in den mix. Zum Beispiel, wenn eine Funktion einen parameter hat, wählt einen Betrieb zu führen, und einige Operationen wieder nützliche Daten, aber andere nicht,...
    • ...dann in den Fällen, in denen ein Anrufer gibt an, ein Vorgang, der nicht wieder nützliche Daten, in der Lage, um zurückzukehren ein nicht initialisiertes Wert erlauben kann, etwas mehr effiziente code-Generierung als laden zu müssen einen sinnlosen Wert.
    • Ich denke, wenn Sie Lesen, die akzeptierte Antwort sorgfältig, es nicht zu sagen, dass dieses Verhalten nur existiert auf Architekturen mit trap-Repräsentationen. Vielmehr heißt es, dass, WENN eine solche Architektur müsste solch ein problem mit einem register variable ist, dann hat der code Undefiniertes Verhalten -- auch wenn das nicht die Architektur, die Sie eigentlich abzielen. Versuchen Sie erneut es zu Lesen und lassen Sie mich wissen, wenn Sie nicht einverstanden sind.
    • Von der akzeptierten Antwort: Solche Variablen werden speziell behandelt, da gibt es Architekturen, die echten CPU-Register, die eine Art von extra-Zustand der "nicht initialisierte" und nicht entsprechen, um einen Wert in den Typ der Domäne. Wenn Sie eine 32-bit-Wert verwendet, für ein uint16_t hat seine Obere bits gesetzt, das entspräche einem Staat außerhalb der Domäne des uint16_t, aber der Prozessor würde die Sie weder kennen noch kümmern, dass das register wird für einen uint16_t, und würden dadurch sehen, nichts besonderes über den Wert in das register.
    • Dieses Zitat spricht über die Behandlung von Variablen, eine C-Konzept. Das, was du gerade gesagt hast, ist über die CPU ist die Behandlung von Registern, bin externe Konzept. Also, natürlich, die CPU muss nicht unbedingt wissen, die Variablen Daten-Typ, aber das ist nicht das, was das Zitat sagt. Das Zitat sagt: "wenn einige Werte außerhalb der Domäne auf EINIGEN Architekturen, das Verhalten ist undefiniert, in der Sprache (d.h. überall), weil auf diesen besonderen Architekturen, könnte es schon eine trap-Darstellung".
    • Das Zitat deutet darauf hin, dass die primäre Grund ist das Verhalten nicht definiert ist, die Existenz von hardware-Registern, die erkennen ein "nicht initialisierte" Zustand. Viel von der C-Norm beruht auf der Philosophie, dass, wenn das Verhalten definiert wurde, die auf einigen Plattformen, aber nicht andere vor C89 veröffentlicht wurde, so dass es undefiniert in der Standard sollte erhalten, dass status quo; eine solche Philosophie hält immer noch viel von der Welt der kommerziellen embedded-Compiler (außer gcc), also die Möglichkeit der seltsame "Natürliche" Verhalten kann sehr wichtig sein in solchen Kontexten.
    • supercat gerne post erweitert Ihre Kommentare als Antworten. Diese nicht-Antwort hat keinen Einfluss auf die Frage oder Ihre Antwort akzeptiert.
    • Die Frage, die fragt "warum" der Standard sagt zu solchen Aktionen aufrufen, UB. Für fast jede Frage "Warum muss Dokument X sagen Y" die offensichtliche richtigen, aber wenig hilfreichen Antwort wäre, "Weil das, was der Autor geschrieben hat", aber das würde sofort die Eingabeaufforderung "Welche Gründe würden die Autoren hatten für das schreiben, dass". Deshalb sehe ich die Fragen, die Sie Fragen, warum Dokument X sagt, Y wie implizit mit der Frage "Welche Gründe würden die Autoren von Dokument X habe für die Aussage Y". Sehen Sie solche Rückschlüsse ungeeignet?

    InformationsquelleAutor supercat
Schreibe einen Kommentar