Macht der C-standard erlauben die Zuweisung eines beliebigen Wertes zu einem Zeiger und der Inkrementierung es?

Ist das Verhalten von diesem code definiert?

#include <stdio.h>
#include <stdint.h>

int main(void)
{
    void *ptr = (char *)0x01;
    size_t val;

    ptr = (char *)ptr + 1;
    val = (size_t)(uintptr_t)ptr;

    printf("%zu\n", val);
    return 0;
}

Meine ich, können wir das zuweisen einer festen Zahl zu einem Zeiger und der Schrittweite, auch wenn es auf einigen zufälligen Adresse? (Ich weiß, dass kann man nicht dereferenzieren es)

  • Haben Sie versuchen, zu kompilieren und laufen lassen?
  • Der Zeiger-Wert ist nur ein Wert, gespeichert in einem Speicher, und Sie können rechnen mit ihm. Wenn Sie versuchen, Rücksicht, es ist dann nur der Wert wird interpretiert als ein Speicher.
  • Kaum ein test von code Gültigkeit. Viel code mit undefiniertem Verhalten "kompiliert und ausgeführt wird".
  • Warum würden Sie wollen, dies zu tun?
  • nur weil der code kompiliert nicht unbedingt, dass es gut definiert Verhalten.
  • ChristianGibbons '... und es laufen'. In Anbetracht der print-Anweisung, es sollten, drucken Sie den Wert 2. Das ist die wohldefiniertes Verhalten überprüfen, mit der rechten gibt. Wenn es druckt nichts anderes, als 2 nicht klar definiert.
  • Welchen Teil von "undefiniert" ist nicht klar? Undefined bedeutet nicht, dass "unerwartete Ergebnisse". Es kann scheinen zu gut funktionieren seit Jahren. Das ist das problem.
  • In Anbetracht der print-Anweisung, es sollten, drucken Sie den Wert 2. Das ist die wohldefiniertes Verhalten überprüfen, mit der rechten gibt. Ich werde direkt zum Punkt: diese Aussage von dir zeigt einen vollständigen Mangel an Verständnis von "undefiniertem Verhalten". "Ich lief, und es auch ausgegeben die Ausgabe, die ich erwartet" sicherlich schließt nicht aus, dass Undefiniertes Verhalten.
  • In anderen Worten, nicht definiertes Verhalten in etwa bedeutet, dass die Spezifikation nicht angeben, was passieren soll. In der Tat, IIRC die Spezifikation definiert, dass jedes Programm mit undefinierten Verhalten kompilieren können, was der compiler will, da es nicht definiert. Gehören beide "kompiliert die perfekt zu den Anweisungen, die Sie erwartet/wanted", aber auch "kompiliert Code in code, der nur druckt 2" und auch "nicht kompiliert". Etwas zu tun, was Sie erwarten können, noch nicht definiertes Verhalten.
  • Unter den Verhaltensweisen, die fallen unter die Beschreibung "undefined" Verhalten "tun genau das, was Sie erwarten, wenn Sie testen wollen, und dann tun Sie etwas ganz anderes, wenn Sie etwas tun, wichtig und/oder überzeugt sich selbst, dass dies nie die Ursache des bugs, die Sie finden".
  • Es ist wirklich, obwohl. Nicht. Wenn Sie haben keine andere Wahl, Sie werden viel glücklicher sein, nicht zu tun, freche Dinge mit Ihnen, und wenn Sie nicht, können Sie wahrscheinlich abstrahieren hinter ein paar Funktionen, damit du wenigstens versuchen nicht, um herauszufinden, ((void(*)(char*))0x20000EE0)("Hello, World!") wenn, dass wäre genauso gut gewesen puts. Das heißt, diese Frage ist sinnvoll, akademisch, es ist gut, zu wissen, was UB/IDB.
  • Code mit Undefiniertem Verhalten ist einfach gebrochen. Kein "wenn"s, die "aber"s oder-nichts - falsch, gebrochen, Punkt. Es mag scheinen, zu tun, was du erwartest jetzt aber ändern-compiler oder compiler-version oder compiler-flags oder OS oder upgrade eine dynamische Bibliothek oder viele andere Dinge, und Sie können sehen plötzlich völlig anders Verhalten. Sie brach die Regeln der Sprache und nicht mehr irgendwelche Garantien auf das, was passieren wird.
  • Dies wird manchmal als "Umsetzung-nicht definiert": es ist die Implementierung definiertes Verhalten, und je nach genau das, was die Implementierung definiert, die follow-up-code möglicherweise oder möglicherweise nicht UB
  • Auch unter Ihnen sind "nachweislich dokumentiert fashion Merkmal der Umwelt". Die Autoren des Standard haben ausdrücklich anerkannt, dass viel von der Nützlichkeit der Sprache kommt von der Tatsache, dass Implementierungen zulassen, die nicht-portable Programme, um Dinge zu tun, die portable Programme nicht können. Sie erwarteten, dass compiler-Schreiber erkennen würden, dass eine hochwertige Umsetzung vorgesehen für low-level-Programmierung auf einer Plattform aussetzen sollte charakteristische Verhaltensweisen, die Plattform, auch wenn die Implementierungen, welche nicht bestimmt sind, geeignet zu sein für solche Zwecke brauchen nicht so.
  • Die Autoren der Norm explizit zu erkennen in der Begründung an, dass eine Umsetzung könnte erfüllen die Anforderungen der Standard-und doch von so geringer Qualität, wie Sie werden im wesentlichen nutzlos. Wäre es nicht möglich, für etwas, was eine Qualität-Implementierung eignet sich für viele Zwecke ist ohne verhält sich vorhersehbar in einigen Fällen, wo die Norm enthält keine Anforderungen, und die Tatsache, dass code für einen bestimmten Zweck wird nicht arbeiten auf etwas anderes als Qualität der Implementierungen, die geeignet sind für diesen Zweck sollte wohl kaum als Mangel angesehen werden.
  • Leider, die Autoren der Standard-Gedanke compiler-Schreiber erkennen würden, dass die Qualität Implementierungen vorgesehen für bestimmte Ziele und Felder der Anwendung müssen (um die Qualität Implementierungen geeignet für diese Zwecke) erwartungsgemäß Verhalten in Fällen, die über jene hinausgehen, die im Auftrag der Standard, ohne den Standard zu müssen ausdrücklich sagen, solche Dinge. Niemand hielt es für nötig, um explizit zu dokumentieren, dass Compiler Verhalten sich sinnvoll in Fällen, wenn, könnte es natürlich sinnvoll, auf den Plattformen, wo Verhalten sinnvoll wäre einfacher und leichter als etwas anderes zu tun.
  • das ist toll, ein toller Kommentar zu versichern, die Programmierer in Nischen-domains, die wissen, wie Sie mit den features, die Ihre compiler-Hersteller garantiert, dass bestimmte Verhalten. Aber es ist ein unglaublich schlechtes Kommentar zu machen in einer Diskussion, wo die Leute denken, "es habe es einmal in ein künstliches Spielzeug-problem" ist der gold-standard für die Bestimmung konsistentes Verhalten.
  • Das problem ist "vernünftig Verhalten" liegt im Auge des Betrachters. Zum Beispiel, ist es natürlich sinnvoll für Compiler zu emittieren effizienten code für alle sinnvollen Eingaben, und denke, dass ist das einzig sinnvolle Verhalten. Andere scheinen, es zu finden mehr sinnvoll für Compiler zu emittieren ineffizient code, wenn das ist, was erforderlich ist, um produzieren spezifische Müll Ausgänge aus Abfall-input.
  • Auf jeder compiler geeignet für low-level oder Systeme, Programmierung, lvalue liest und schreibt wird das Natürliche Verhalten definiert, in Bezug auf die Umwandlung eines Musters von bits, die einen Wert eines gegebenen Typs ist, oder konvertieren Sie einen Wert eines bestimmten Typs in einem Muster von bits. Während eine Umsetzung geeignet sein können für low-level-Programmierung ohne Verhalten sich in diesem Mode in allen nur denkbaren Umständen, jemanden sucht, eine Qualität zu produzieren Implementierung geeignet für low-level-Programmierung zu unterstützen Semantik, die erzielbar wären mit einem solchen Verhalten, und sollten bei der praktischen...
  • ...versuchen Sie Verhalten sich in diesem Mode in nicht-erfundene Fälle, in denen es wahrscheinlich egal ist (wenn die Kunden beschweren sich über die Fälle, wo es nicht, das ist ein ziemlich gutes Zeichen, dass die Fälle nicht egal). Ich würd Hinsicht ein compiler, der könnte sicher Unterstützung von einem leicht erkennbaren 90% von low-level-Programme, während das erreichen 80% der theoretisch erzielbaren Optimierungen wie überlegen man, die konnte nicht zuverlässig unterstützt viele low-level Programme ohne deaktivieren fast alle Optimierungen.
  • Etwas weiter gefasst, die meisten Programme haben eine Allgemeine Anforderung "gegeben, Wenn gültige Eingabe Gültiger Ausgang; wenn gegeben ungültige Eingabe verzichten, der den Start von Atomraketen". Eine gute Sprache sollte ermöglichen, ein Programmierer, um erfüllen sowohl die Anforderungen als auch ohne viel mehr Aufwand, als notwendig wäre, sich zu treffen nur das erste mal. Viele "Optimierungen" dass Implementierungen zur Verbesserung der code-Effizienz, erfüllt nur die erste Voraussetzung, aber auf Kosten der Erhöhung der Menge der Arbeit, die Programmierer tun müssen, um die zweite, und in vielen Fällen die Verringerung der Effizienz solcher code.

InformationsquelleAutor David Ranieri | 2018-06-28
  1. 68

    Zuordnung:

    void *ptr = (char *)0x01;

    Ist Umsetzung definiert Verhalten, denn es ist die Umwandlung eines integer zu einem pointer. Dies ist ausführlich in Abschnitt 6.3.2.3 der C-standard in Bezug auf Zeiger:

    5 Eine Ganzzahl umgewandelt werden kann, um jeden Zeiger-Typ. Außer wie zuvor angegeben, das Ergebnis wird durch die Implementierung festgelegt,
    möglicherweise nicht richtig ausgerichtet ist, kann nicht auf eine Person
    der referenzierte Typ, und könnte eine trap-Darstellung.

    Als für die nachfolgenden Zeiger-Arithmetik:

    ptr = (char *)ptr + 1;

    Dies ist abhängig von ein paar Dinge.

    Zunächst der aktuelle Wert der ptr kann eine trap-Darstellung als pro 6.3.2.3 oben. Wenn es ist, das Verhalten ist undefined.

    Nächste ist die Frage, ob 0x1 Punkte auf ein gültiges Objekt. Hinzufügen eines pointer und eine integer ist nur gültig, wenn sowohl die pointer Operanden und das Ergebnis zeigen Sie auf Elemente eines array-Objekt (ein einzelnes Objekt gilt als ein array der Größe 1) oder ein element nach dem array-Objekt. Dies ist ausführlich in Abschnitt 6.5.6:

    7 Für die Zwecke dieser Operatoren, die einen Zeiger auf ein Objekt, das kein element eines Arrays verhält sich wie eine
    Zeiger auf das erste element in einem array der Länge eins mit dem Typ
    des Objekts als element-Typ

    8, Wenn ein Ausdruck mit integer-Typ ist, addiert oder subtrahiert einen Zeiger, der auf das Ergebnis hat den Typ des Zeigers
    operand. Wenn die pointer Operanden Punkte, um ein element eines Arrays
    Objekt und das array ist groß genug, das Ergebnis verweist auf ein element
    offset von der ursprünglichen element derart, dass die Differenz der
    die Indizes der resultierenden und der original-array-Elemente, entspricht der
    integer-Ausdruck. In anderen Worten, wenn der Ausdruck P Punkte der
    i-te element eines array-Objekts, die Ausdrücke (P)+N (in ähnlicher Weise, N+(P) ) und (P)-N (wo N hat den Wert n ) zeigen Sie auf,
    beziehungsweise, der ich+n-th und th-Elemente des array-Objekts, sofern Sie vorhanden sind. Außerdem, wenn der Ausdruck P Punkte, um das Letzte element einer
    array-Objekt, der Ausdruck (P)+1 Punkte, die man hinter das Letzte element
    das array-Objekt, und, wenn der Ausdruck Q Punkte einer Vergangenheit, die
    das Letzte element eines array-Objekts, den Ausdruck (Q)-1 Punkte zu
    das Letzte element des array-Objekts. Wenn sowohl der Zeiger
    Operanden und das Ergebnis zeigen Sie auf Elemente des gleichen Arrays
    Objekt, oder eine hinter dem letzten element des array-Objekts, die
    Bewertung wird nicht zu einem überlauf; ansonsten ist das Verhalten
    undefined.     Wenn das Ergebnis der Punkte, die man hinter das Letzte element des
    array-Objekt ist, muss es nicht verwendet werden, die als Operanden eines unären
    * operator ausgewertet wird.

    Auf eine hosted-Implementierung der Wert 0x1 fast sicherlich nicht nicht zeigen Sie auf ein gültiges Objekt, in welchem Falle der Zusatz undefined. Eine eingebettete Implementierung könnte jedoch die Unterstützung der Einstellung der Zeiger auf bestimmte Werte, und wenn ja, könnte es der Fall sein, dass 0x1 hat in der Tat zeigen Sie auf ein gültiges Objekt. Wenn dem so ist, ist das Verhalten gut definiert, sonst ist es undefined.

    • Ich wunderte mich darüber, dass in Abschnitt 6.5.6 und wie es gilt für diesen Fall. wenn (char *)ptr ist betrachtet zu sein, zeigt auf das erste element eine 1-element-array, dann würde (char *)ptr + 1 nicht zeigen, eine Vergangenheit, die das Letzte element einer 1-element-array?
    • Dein Zitat von p8 wäre dann relevant, wenn die OP nicht +1. Aber... Es gibt p7 zu betrachten.
    • Erbsenzählerei. Nur für die Vollständigkeit, char Zeiger sind erlaubt, pointer-Arithmetik, wenn Sie auf einen Punkt im inneren eines Objekts, unabhängig von der Art (aus 6.3.2.3 § 7 Entwurf n1570 für C11). Auf jeden Fall ist es hier irrelevant...
    • Einen Zeiger können Sie einen Wert von einem über das Ende des array müssen Sie aber nicht dereferenzieren es dort.
    • Recht. OP angegeben, dass es keine Dereferenzierung der Zeiger, nur die Zeiger-Arithmetik.
    • Ich denke, dass die Zeiger-Arithmetik ist, ist die Implementierung definiert, denn: Die Zuweisung wird durch die Implementierung definiert. Wenn die Umsetzung der Ergebnisse in einen Zeiger in eine char-array, dann ptr + 1 gut definiert ist. Auf der anderen Seite, wenn die Umsetzung gibt z.B. eine Falle, dann ist es UB.
    • Ich glaube nicht, dass die Umsetzung definiert Verhalten erlaubt ist zu undefiniert. Aber ich weiß, was du versuchst zu sagen-ob oder ob nicht der Zusatz ist Undefiniertes Verhalten, hängt von der Implementierung definierte Entscheidungen.
    • Umwandlung in eine Falle der Vertretung ist innerhalb akzeptabler Umsetzung definiert Verhalten. Siehe 6.3.2.3/5
    • “Der Zeiger zeigt nicht auf ein gültiges Objekt“ — Was fehlt ist diese Antwort eine Erklärung, was wäre ein gültiges Objekt; und insbesondere, warum der pointee nicht ein (evtl. Implementierung festgelegt) gültiges Objekt. Ich kenne nur die relevanten Regeln für C++, nicht in C, also ich bin echt neugierig.
    • Streng genommen, könnte man dann nicht gut definiert eine bestimmte Implementierung? d.h. wenn (int *)0x01 definiert war durch meine fiktionale Umsetzung WeirdC auf einen gültigen char-array, möchten Sie, dass der rest genauso gültig, wenn auch nur auf WeirdC? Ich Frage, weil dies ist relevant für z.B. embedded-Entwicklung, wo Sie vielleicht auch mit Zeigern um einen bestimmten ganzzahligen Wert um Daten zu ändern.
    • Sind Sie richtig. Ich habe mit einer zusätzlichen Erklärung zu den Fällen, wenn der Zusatz könnte definiert werden vs. nicht definiert.
    • Der cast könnte Ergebnis in a one-past-the-end-Zeiger, in dem Fall hinzufügen 1 es ist undefiniert
    • Wenn die Umsetzung der Auffassung gesamten adressierbaren Speichers als ein Objekt (alles andere tut es verhindern?), dann (char*)1 wahrscheinlich Punkte drin, dann alle arithmetischen sollte es sein, gut definiert.
    • Das ist im Grunde das, was jeder C-compiler auf hardware, die nicht über eine trap-Darstellung. Aber es ist immer noch alle Durchführung definiert Verhalten. Konvertierung von int nach Zeiger bereits die Umsetzung definiert. Es muss nicht einmal eine Adresse zeigt auf 0x1. Es ist nur so, dass die meisten Implementierungen haben die int-Zeiger-Konvertierung einfach zu bewahren, die bit-Muster (da ist ein NOP) und die meisten hardware haben den gesamten adressierbaren Speichers als ein Objekt.

    InformationsquelleAutor dbush
  2. 18

    Nein, das Verhalten des Programms ist undefiniert. Sobald eine Undefinierte Konstrukt erreicht wird, das in einem Programm, jede zukünftige Verhalten ist nicht definiert. Paradoxerweise keine Vergangenheit Verhalten ist undefiniert zu.

    Ergebnis void *ptr = (char*)0x01; wird durch die Implementierung festgelegt, zum Teil aufgrund der Tatsache, dass ein char kann eine trap-Darstellung.

    Aber das Verhalten der folgenden Zeiger-Arithmetik in der Anweisung ptr = (char *)ptr + 1; ist undefined. Dies ist, weil die Zeiger-Arithmetik ist nur gültig innerhalb von arrays, einschließlich einer über das Ende des Arrays. Für diesen Zweck ist, ein Objekt, ein array der Länge eins.

    InformationsquelleAutor Bathsheba
  3. 8

    Ja, der code ist gut definiert als die Implementierung festgelegt. Es ist nicht undefiniert. Siehe ISO/IEC 9899:2011 [6.3.2.3]/5 und Anmerkung 67.

    Die Sprache C wurde ursprünglich als ein system-Programmiersprache. Systeme Programmierung erforderlich Manipulation von memory-mapped hardware, die erfordern, dass Sie würde Zeug hart-codierte Adressen in Zeigern, manchmal Inkrementieren Sie diese Hinweise, und Lesen und schreiben von Daten von und an die resultierende Adresse. Zu diesem Zweck zuweisen und integer zu einem pointer und Manipulation, die Zeiger mithilfe von arithmetischen ist auch durch die Sprache bestimmt ist. Indem Sie durch die Implementierung festgelegt, was die Sprache ermöglicht wird, dass alle möglichen Dinge können passieren: von der klassisch-halt-und-catch-fire " zu der Erziehung eines bus-Fehler beim dereferenzieren eine ungerade Adresse.

    Den Unterschied zwischen dem undefinierten Verhalten und Implementierung-definiert das Verhalten ist im Grunde ein Undefiniertes Verhalten bedeutet, "tun Sie das nicht, wir wissen nicht, was passieren wird" und implementierungsspezifische Verhalten bedeutet "es ist OK, gehen Sie vor und tun, es ist bis zu Ihnen, zu wissen, was passieren wird."

    • "Manipulation, die Zeiger mithilfe von arithmetischen ist auch durch die Sprache bestimmt ist" — Zitat benötigt.
    • Der Sprache standard explizit definiert, dass die Zeiger-Arithmetik ist nur gültig innerhalb der Grenzen eines Objekts
    • Ich denke, es ist ziemlich klar, dass dies UB in die C standard (weil in der Regel die Schaffung eines pointer ausserhalb der Grenzen eines Objekts), aber viele Implementierungen legen das Verhalten der Zeiger in mehr Fällen, als der C-standard gibt. wenn Sie z.B. nicht dereferenzieren Sie auf vielen Implementierungen ist es sicher zu schaffen, Zeiger, zeigen Sie nicht in jedem Objekt.
    • Der Standard macht keinen Versuch, das Mandat, dass alle Implementierungen werden passend für low-level-Systeme, Programmierung, noch ist es in irgendeiner Weise implizieren, dass es möglich sei, eine Qualität-Implementierung, die ist geeignet für low-level oder Systeme, die eine Programmierung ohne es unterstützt Verhaltensweisen, die über jene hinausgehen, die im Auftrag der Standard (und die möglicherweise nicht verarbeitet werden erwartungsgemäß von Implementierungen, die nicht für Systeme geeignet, die Programmierung).
    InformationsquelleAutor Stephen M. Webb
  4. 8

    Es ist Undefiniertes Verhalten.

    Vom N1570 (Hervorhebung Hinzugefügt):

    Einen integer umgewandelt werden kann, um jeden Zeiger-Typ. Außer wie zuvor angegeben, das Ergebnis wird durch die Implementierung festgelegt, möglicherweise nicht richtig ausgerichtet ist, kann nicht auf eine Entität, auf die verwiesen wird, geben, und könnte eine Falle sein Darstellung.

    Wenn der Wert eine trap-Darstellung, das Lesen, es ist Undefiniertes Verhalten:

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

    Und

    Ein Bezeichner ist eine primäre Ausdruck, vorausgesetzt, er wurde deklariert als Benennung eines Objektes (in dem Fall es ist ein lvalue) oder eine Funktion (in dem Fall ist es eine Funktion, Bezeichner).

    Daher, die Linie void *ptr = (char *)0x01; ist bereits möglicherweise nicht definiertes Verhalten, auf eine Umsetzung, wo (char*)0x01 oder (void*)(char*)0x01 ist eine trap-Darstellung. Die linke Seite ist ein lvalue-Ausdruck, der keine Charakter-Typ und liest eine trap-Darstellung.

    Hardware, das laden einer ungültigen Zeiger in eine Maschine zu registrieren, könnte das Programm zum Absturz bringen, so war dies eine erzwungene Bewegung durch den Normen-Ausschuss.

    • So weit ich das beurteilen kann, sogar auf Plattformen, wo die Belastung mit einem ungültigen Zeiger in eine Maschine registrieren auslösen könnte eine Falle, die Aussage int *p = (int*)someValue; würde definiert haben, Verhalten, wenn nichts versucht, den Zeiger in p, unabhängig davon, ob der Ausdruck liefert einen gültigen Zeiger. Waren das nicht der Fall, das Konstrukt würde immer aufrufen Undefiniertes Verhalten, da es--genau wie bei UB--das Verhalten würde sein Verhalten sinnvoll auf Implementierungen, die festlegen, nützliches Verhalten, und Verhalten sich unvorhersehbar auf Implementierungen, die nicht.
    • Es scheint mir, dass auf einer Maschine, wo (char*)0x01 waren eine trap-Darstellung, ptr im Ausdruck void *ptr = (char*)0x01; ist ein lvalue-Ausdruck, der liest diesen Wert und keinen Charakter geben, erklärte UB? Wenn nicht, wird die nächste Zeile, die verwendet ptr definitiv ist. Bin ich Missverständnis?
    • Die Linie, die verwendet liest ptr und wirft es zu uintptr_t aufrufen würden UB, wenn (char*)1 waren eine trap-Darstellung. Die Präsenz in den Ausdruck ein lvalue, der hält, was eine trap-Darstellung, allerdings nur ruft UB in Fällen, in denen die lvalue ist ausgewertet. In der Erklärung void *ptr = (char*)0x01; es ist jedoch kein lvalue, und wenn die Erklärung und speichern Sie wurden abgespalten, wie in void *ptr; ptr = (char*)0x01; die Anweisung nach der Deklaration enthalten würde, die lvalue ptr, aber schreiben würde, dass lvalue, ohne zu bewerten.
    • Ich zitiere den Abschnitt der (draft) standard, der besagt, dass ein Bezeichner ist ein lvalue, und für einen lvalue (wie ptr), dessen Typ nicht ein Zeichen geben (wie void*) zu Lesen, eine trap-Darstellung ist schon UB. So, ein compiler würde emittieren dürfen, eine Maschinen-Instruktion zu Lesen, die ungültige bit-Muster in einer Adresse oder segment-register, auf einer CPU, wo Sie dazu führen würde, dass ein hardware-Falle. Interpretiert man die Norm anders, dann können wir immer noch vereinbaren, dass die Schrittweite wird UB in diesem Fall?
    • Und das ist eine vernünftige Verhalten charakteristisch für viele Umgebungen. Viele Architekturen, darunter x86 mit segment-Register in den geschützten Modus, haben trap Darstellungen für Zeiger, und das erwartete Verhalten eines int-to-pointer-conversion konnte gut sein zu laden, dass eine exakte bit-Muster und Schießen selbst in den Fuß.
    • Ich werde Zustimmen, dass die Standard-nicht erforderlich-Implementierungen zu definieren, die das Verhalten der Auswertung ein lvalue vom Typ Zeiger, noch würde es erfordern Implementierungen zu definieren, die das Verhalten der addition von 1 zu einem Zeiger gebildet, der aus einem integer-to-pointer-cast in jedem Fall (außer, wenn der Wert umgewandelt werden, ist eine Null-Zeiger-Konstante), obwohl die Qualität Implementierungen sollten mindestens definieren, die ein solches Verhalten in Fällen, in denen der integer-Wert in Frage, wurde erzeugt durch die Umwandlung eines Zeigers auf intptr_t oder uintptr_t.
    • Aber halten Sie im Verstand, viele ISAs haben, bitfields, in deren Zeiger oder word-Adressierung. Streng definieren das Ergebnis der Inkrementierung eine Besetzung Zeiger schließt die Natürliche und effiziente Umsetzung.
    • Ich sage nicht, dass Sie Implementierungen für alle Architekturen erwartet werden sollte, um zu definieren, den Effekt der Anwendung erhöhen jeder möglich Zeiger, aber wenn das Standard würde definieren Sie das Verhalten von Inkrementieren eines bestimmten Zeigers, dann setzen Sie es durch eine hin-und Rückreise zum/vom uintptr_t und dann Inkrementieren dem Ergebnis, dass die Konvertierung (im Gegensatz zur Erhöhung der ursprünglichen uintptr_t) nachgeben sollten das gleiche Verhalten auf eine hochwertige Umsetzung.
    • Es ist eine Garantie, "Zwei Zeiger vergleichen gleich, wenn und nur wenn beide null-Zeiger, beide sind Zeiger auf das gleiche Objekt (einschließlich eines Zeigers auf ein Objekt und Unterobjekt am Anfang) oder die Funktion, beide sind Zeiger auf eine Vergangenheit, die das Letzte element des array-Objekt, oder ist ein Zeiger auf eine über das Ende eines array-Objekts und der andere ist ein Zeiger auf den start in ein anderes array-Objekt, das geschieht gleich im Anschluss an das erste array-Objekt in dem Adressraum." Das impliziert für mich, dass der Zeiger der Vergleich gleich ist, muss ein Gültiger Zeiger auf das gleiche Objekt.
    • Angesichts struct { int x[1],y[1]; } it; compiler kann (und für die meisten Compiler, wahrscheinlich wäre) Lagen die Dinge so, dass nach int *p = it.x+1, *q = it.y; -, Zeiger - p und q würde vergleichen Sie gleich aber nicht identisch sein. Setzen Sie p oder q durch eine round-trip-Konvertierung durch uintptr_t ergeben könnte entweder p oder q, entschieden im Unbestimmten Mode [da Sie im Vergleich gleich, entweder wäre zulässig]. Folglich ist nur die Operationen, die getan werden könnte, auf das Ergebnis dieser Umwandlung sein, die gültig sind, die auf beiden p und q.
    • Tun Sie Zustimmen oder nicht Zustimmen, dass in einer situation wie der oben p und q vergleichen konnte gleich ohne nutzbaren Zugriff auf den gleichen Speicher? Ich sehe keinen Grund, die Standard sollten nicht garantieren, dass ein round-trip-Konvertierung von einem Zeiger durch uintptr_t innerhalb der Lebensdauer des original-Zeiger Ziel unterordnen müssen einen Zeiger, der kann Zugriff auf alles, was das original konnte, aber der Standard nicht wirklich sagen, eine solche Sache.
    • Lassen Sie uns weiter, diese Diskussion im chat.

    InformationsquelleAutor Davislor
  5. 3

    Der Standard verlangt nicht, dass Implementierungen Prozess integer-to-Zeiger Konvertierungen in eine sinnvolle Art und Weise für einen bestimmten integer-Werte, oder auch für alle möglichen ganzzahligen Werte außer Null-Zeiger-Konstanten. Das einzige, was es garantiert zu solchen Umbauten ist, das ein Programm speichert das Ergebnis der Konvertierung direkt in ein Objekt vom passenden Typ pointer und macht nichts mit, außer das prüfen der bytes des Objektes, im schlimmsten Fall, siehe Unbestimmte Werte. Während das Verhalten der Umwandlung eines integer zu einem pointer wird durch die Implementierung Festgelegt, würde nichts verbieten alle Umsetzung (egal, was es tatsächlich mit solchen Umbauten!) aus der Angabe, dass einige (oder sogar alle) der bytes der Darstellung mit Unbekannter Werte, und die Angabe, dass einige (oder sogar alle) integer-Werte können sich Verhalten, als ob Sie ein Rendite-trap-Repräsentationen.

    Die einzigen Gründe, die Norm sagt überhaupt nichts über integer-to-Zeiger Konvertierungen sind:

    1. In einigen Implementierungen das Konstrukt sinnvoll ist, und einige Programme für die Implementierungen erfordern.

    2. Die Autoren der Norm haben, die nicht wie die Idee, ein Konstrukt, das verwendet wurde, auf einige Implementierungen darstellen würde eine constraint-Verletzung auf andere.

    3. Wäre es gewesen, seltsam für den Standard zu beschreiben, ein Konstrukt, aber dann angeben, dass es hat nicht definiertes Verhalten in allen Fällen.

    Persönlich, ich denke, die Standard haben sollte erlaubt Implementierungen zur Behandlung von integer-to-Zeiger Konvertierungen als constraint-Verletzungen, wenn Sie nicht definieren alle Situationen, in denen Sie hilfreich wäre, anstatt zu verlangen, dass die Compiler akzeptieren den Sinn der Codes, aber das war nicht der Philosophie der Zeit.

    Denke ich, wäre es am einfachsten sein, einfach zu sagen, dass jede operation mit integer-to-Zeiger Konvertierungen mit etwas anderem als intptr_t oder uintptr_t empfangenen Werte von pointer-auf-integer-Konvertierungen ruft Undefiniertes Verhalten, aber beachten Sie, dass es üblich ist für die Qualität der Implementierungen vorgesehen für low-level-Programmierung zur Prozess zu Undefiniertem Verhalten "in einer Weise dokumentiert Merkmal der Umwelt". Der Standard ist nicht angegeben, wenn die Implementierungen verarbeiten sollen Programme, aufrufen von UB in die Mode sondern behandelt es als eine Qualität der Umsetzung Problem.

    Wenn eine Implementierung gibt an, dass integer-to-Zeiger Konvertierungen funktionieren in einer Weise, die würde definieren Sie das Verhalten von

    char *p = (char*)1;
p++;

    als äquivalent zu "char p = (char)2;", dann die Umsetzung, wie man erwarten sollte, das es so funktioniert. Auf der anderen Seite konnte die Umsetzung definieren Sie das Verhalten von integer-to-pointer-conversion, so dass auch:

    char *p = (char*)1;
char *q = p;  //Not doing any arithmetic here--just a simple assignment

    würden release-Nasen-Dämonen. Auf den meisten Plattformen, einem compiler, wo arithmetische Operationen auf Zeigern produziert von integer-to-Zeiger Konvertierungen benahm sich seltsam, würde nicht gesehen werden, als eine qualitativ hochwertige Umsetzung geeignet für low-level-Programmierung. Ein Programmierer, der nicht beabsichtigt, eine beliebige andere Art von Implementierungen könnten somit erwarten, dass solche Konstrukte zu Verhalten sinnvoll auf die Compiler, die den code, der geeignet war, obwohl der Standard verlangt es nicht.

    • wenn char *p = (char *)1; nicht die Ursache UB dann die weitere Zuordnung zu q würde nicht entweder. Die erste Stufe des Problems kommt mit der Folge der Besetzung zugewiesen wird p
    • Wenn ein lvalue hält eine trap-Darstellung, es zu Lesen, produzieren, UB. Da der Standard-nicht erlaubt, einen integer-to-pointer-conversion etwas anderes zu tun als Ertrag einen Zeiger, noch stellt er fest, dass die Speicherung einen Zeiger in einem vorhandenen Objekt vom entsprechenden Typ kann nichts anderes tun, als änderung des Inhalts des Objekts.
    • Der standard ermöglicht es, die integer-Zeiger-Konvertierung liefern eine trap-Darstellung und Speicherung, die in p würde dazu führen, UB
    • In welchen Fällen ist die Handlung von speichern eine trap-Darstellung Ertrag UB? Der Standard sagt ausdrücklich, dass die Aktion liefert einen Zeiger, der kann eine trap-Darstellung, anstatt zu sagen, dass die Aktion berufen kann UB. Wenn der cast an sich könnte invoke UB, das würde natürlich erlauben, Sie liefern eine trap-Darstellung, sondern sagen, so sinnlos wäre, da die Besetzung erlaubt wäre, etwas anderes zu tun zu löschen. Beachten Sie, dass "möglicherweise" ist ziemlich vage Frage, ob es in der Bewilligung, um die Umsetzung zu tun, etwas anderes als Ausbeute ein Zeiger auf ein gültiges Objekt oder...
    • ...ist die Erlaubnis für den Programmierer bilden solche ohne Zeiger aufrufen UB, vorausgesetzt, dass der Zeiger nicht tatsächlich in einer Art und Weise ungültig [und, wie erwähnt, ich weiß von nichts darauf hin, dass der Akt der Speicherung alles in einem legitimen Objekt von einem bestimmten Typ mit einem lvalue der Typ kann nichts anderes tun, als das alter der gespeicherte Wert in das Objekt].
    • Natürlich, die Autoren der Standard nicht viel Aufwand zum Bearbeiten von Aktionen, die wäre sinnvoll und notwendig, auf einigen Plattformen und Anwendungs-Felder, in anderen aber nicht. Gelegentlich werden Sie sagen, solche Aktionen sollten definiert Verhalten auch auf Plattformen/Felder, wo Sie würde keinem Zweck dienen. Oft, Sie aufrufen UB auch auf Plattformen/Felder, wo es sinnvoll und nötig. Wenn die Qualität von Implementierungen für solche Plattformen erwartet werden kann, verarbeiten Sie in einer Weise charakteristisch für die Umwelt, unabhängig davon, was die Standard-Mandate...
    • ...sollte es nicht eigentlich egal, ob der Standard definiert ein solches Verhalten oder nicht. Der einzige Grund, warum diese Probleme problematisch ist, dass einige compiler-Autoren werden mehr daran interessiert, bei der Identifizierung von Fällen, die betrachtet werden können, wie das aufrufen UB als in Fällen, in denen Plattformen wäre nützlich, charakteristische Verhaltensweisen, die Programmierer von nutzen sein könnten oder sich verlassen.
    • Vereinbart. In der Theorie, der Standard garantiert nicht viel mehr als round-trip compatibility. In der Praxis, die Menschen wollen in der Lage sein zu kompilieren, Kernel und Gerätetreiber, die sich mit absoluten Adressen.
    • Auch beim round-tripping, die Norm enthält keine Anforderungen, die über das, was passiert, wenn code etwas mit der daraus resultierenden Zeiger anderes als vergleichen, die es für die Gleichstellung mit anderen Zeigern. Offensichtlich eine Qualität, die Umsetzung sollte in der Lage sein zu bieten behavioral garantiert in vielen solchen Fällen, aber der Standard nicht erforderlich ist es.

    InformationsquelleAutor supercat
Schreibe einen Kommentar