(lesender) Zugriff auf dafault-initialized Array Members UB?

[Swordfish]

...

[dranhaber]

In C ist es UB, in C++ vermute ich mal genauso:

3.17.2
indeterminate value
either an unspecified value or a trap representation

Der einzige Typ, der in C keine Trap value hat, ist unsigned char.

[camper]

n3337 schrieb:

4.1 Lvalue-to-rvalue conversion [conv.lval]
1 A glvalue (3.10) of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete
type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not
an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program
that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the prvalue is
the cv-unqualified version of T. Otherwise, the type of the prvalue is T.54

[Sone]

Ja, aber das ist ja gerade der Punkt: default-initialized heißt initialized. uninitialized hieße, dass du bspw. durch die Initialisierungsliste auf ein Member zugreifst welches noch gar nicht initialisiert wurde (da es nach dem Member deklariert ist was gerade initialisiert wird). Dein Beispiel ist natürlich vollkommen in Ordnung.

[knivil]

Swordfish schrieb:

der Zugriff auf default-initialized Array Members UB sei oder nicht.

int foo[ 10 ];
for( std::size_t i = 0; i < sizeof foo / sizeof *foo; ++i )
    std::cout << foo[ i ];

Ich sehe ebenfalls nicht, dass der Zugriff UB sein sollte, hoechstens das der Wert undefiniert bzw. willkuerlich ist.

[camper]

Sone schrieb:

Ja, aber das ist ja gerade der Punkt: default-initialized heißt initialized.

Dann wirst du erklären müssen, welche Magie
"otherwise, no initialization is performed."
doch zu einer Initialisierung (=Speichern eines bestimmten Anfangswertes in einer Variablen) führt.

[Sone]

camper schrieb:

Sone schrieb:

Ja, aber das ist ja gerade der Punkt: default-initialized heißt initialized.

Dann wirst du erklären müssen, welche Magie
"otherwise, no initialization is performed."
doch zu einer Initialisierung (=Speichern eines bestimmten Anfangswertes in einer Variablen) führt.

Ich habe mich selber in die Falle gelockt.
Nein, es wird nicht initialisiert, nicht wie du es (richtig) definiert hast.
Aber.

if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.

Der Standard sagt, dass das Objekt einen Wert hat, was impliziert, dass es vollständig konstruiert wurde.

Ich habe mich nur durch den Standard verwirren lassen, der default-initialization nicht immer zusammen schreibt. Beispiel:

If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type with a user-provided default constructor.

Also wenn default initialization != initialization, dann ist der Standard wirklich sehr ... inkonsistent was die Namensgebung angeht.

[tupfaufdemi]

Sone schrieb:

Ich habe mich nur durch den Standard verwirren lassen, der default-initialization nicht immer zusammen schreibt. Beispiel:

If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type with a user-provided default constructor.

Also wenn default initialization != initialization, dann ist der Standard wirklich sehr ... inkonsistent was die Namensgebung angeht.

default initialization != default-initialization != initialization

Logisch. Sind ja drei unterschiedliche Ausdrücke.

[camper]

Sone schrieb:

Aber.

if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.

Der Standard sagt, dass das Objekt einen Wert hat, was impliziert, dass es vollständig konstruiert wurde.

Da liest du, glaube ich, zuviel hinein. Es geht ja ohnehin nur um Sklare oder Arrays aus Skalaren. Von Konstruktion zu sprechen, ist hier also schon mal fehl am Platz.

M.A.n sagt die Passage nicht viel mehr aus, als dass der an der Stelle des Objektes gespeicherte Wert tatsächlich der Wert dieses Objektes ist und nicht etwa ein Überbleibsel eines Objektes, da vielleicht vorher dort existiert hat. Das ist wesentlich in Hinblick auf die Aliasregeln:

n3337 schrieb:

3.10/10 Lvalues and rvalues [basic.lval]
If a program attempts to access the stored value of an object through a glvalue of other than one of the
following types the behavior is undefined:52
...

Das maßgebliche Objekt ist das neu deklarierte Objekt, nicht das alte, in das der alte Wert ursprünglich geschrieben wurde.

Nicht alle Initialisierungsformen werden in Abschnitt 8.5 behandelt. Ein wichtiger Fall wir in 3.9/2 (memcpy&co.) genannt.

int a = 10;
int b; // b hier nicht initialisiert
memcpy( &b, &a, sizeof b );
cout << b; // b ist hier (nat.) initialisiert

allerdings spezifiziert 3.9/2 nicht ausdrücklich die Methode, mit der diese Kopie gemacht wird, man könnte ja auch direkt selbst Bytes kopieren.

Das führt aber zu einem Problem:

void mymemcpy(void* dst, const void* src, size_t size)
{
    char* dst_ = (char*)dst;
    const char* src_ = (const char*)src;
    while ( size-- )
        *dst_++ = *src_++;
}

int foo()
{
    char x[10];
    char y[10];
    mymemcpy(y,x,10); // definiert oder UB?
}

das soll wahrscheinlich wohldefiniert sein, allerdings wird es jedenfalls nicht ausdrücklich im Standard erlaubt.

[hustbaer]

camper schrieb:

int foo()
{
    char x[10];
    char y[10];
    mymemcpy(y,x,10); // definiert oder UB?
}

das soll wahrscheinlich wohldefiniert sein, allerdings wird es jedenfalls nicht ausdrücklich im Standard erlaubt.

Das ist natürlich nicht erlaubt. Hast du vielleicht ein = {} bei char x[10] vergessen?

[camper]

hustbaer schrieb:

camper schrieb:

int foo()
{
    char x[10];
    char y[10];
    mymemcpy(y,x,10); // definiert oder UB?
}

das soll wahrscheinlich wohldefiniert sein, allerdings wird es jedenfalls nicht ausdrücklich im Standard erlaubt.

Das ist natürlich nicht erlaubt. Hast du vielleicht ein = {} bei char x[10] vergessen?

Nichts vergessen. Und wir haben

n3337 3.9/2 schrieb:

For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object
holds a valid value of type T, the underlying bytes (1.7) making up the object can be copied into an array of char or unsigned char.40[/quote

Dies Passage ist m.A.n. die Lizenz, den Zustand jedes beliebigen trivial kopierbaren Objektes untersuchen zu dürfen. In diesem Fall (char/unsigned char) ist nun Objekt- und Wertrepräsentation identisch, so dass beim Kopieren

*dst_++ = *src_++;

einerseits der Wert des Objektes als auch die zugrundeliegenden Bytes kopiert werden.

[hustbaer]

Uff. Hab ich wiedermanl Mist geschrieben.
Danke für die Erklärung!

Also so wie ich das jetzt verstehe:

void foo()
{
    int a, b, c, d;

    memcpy(&b, &a, sizeof(a));   // OK
    mymemcpy(&c, &a, sizeof(a)); // OK
    d = a;                       // UB
}

[camper]

hustbaer schrieb:

Uff. Hab ich wiedermanl Mist geschrieben.
Danke für die Erklärung!

Also so wie ich das jetzt verstehe:

void foo()
{
    int a, b, c, d;

    memcpy(&b, &a, sizeof(a));   // OK
    mymemcpy(&c, &a, sizeof(a)); // OK
    d = a;                       // UB
}

Ist jedenfalls meine Ansicht. Ausserdem

struct foo { int x; };
void bar()
{
    foo bar;
    foo bar = baz; // ok
    cout << bar.x; // UB
    cout << baz.x; // ??? wahrscheinlich ok
}

Noch spannender wird das, wenn man den Copyctor selbst definiert.

[hustbaer]

Hm...
Ich hätte gesagt

void bar()
{
    foo bar;
    foo baz = bar; // keine Ahnung
    cout << bar.x; // UB
    cout << baz.x; // UB
}

[Sone]

Von Konstruktion zu sprechen, ist hier also schon mal fehl am Platz.

Da meinte ich eher, dass das Objekt, hier ein Skalar, in einem gültigen (=benutzbaren) Zustand ist.
Ich traue aber meinen Augen nicht, wenn ich lese,

int a, b = a;

Soll UB sein. Nur da der Wert nicht spezifiziert ist, heißt das doch nicht, dass man ihn nicht benutzen darf...

Dies Passage ist m.A.n. die Lizenz, den Zustand jedes beliebigen trivial kopierbaren Objektes untersuchen zu dürfen.

Aber ein Array ist doch kein Objekt.

[Sone]

foo baz = bar; // keine Ahnung

Wohldefiniertes Verhalten, da ein Kopierkonstruktor implizit definiert wurde. Und bar ist zu dem Zeitpunkt ein lvalue das auf ein vollständig konstruiertes Objekt verweist. Wo könnte da auch nur annähernd ein Problem sein?

[camper]

Sone schrieb:

Nur da der Wert nicht spezifiziert ist,

ist er nicht.
Der Wert ist unbestimmt (indeterminate), was etwas völlig anderes als unspezifiziert darstellt, an anderer Stelle ist im Standard von singulären Iteratoren und ungültigen Zeigern die Rede, was im Grunde das gleiche Konzept ist. Die dürfen auch nicht angefasst werden.

[Sone]

camper schrieb:

Sone schrieb:

Nur da der Wert nicht spezifiziert ist,

ist er nicht.
Der Wert ist unbestimmt (indeterminate), was etwas völlig anderes als unspezifiziert darstellt, an anderer Stelle ist im Standard von singulären Iteratoren und ungültigen Zeigern die Rede, was im Grunde das gleiche Konzept ist. Die dürfen auch nicht angefasst werden.

Ich sehe unspezifiziert als

Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine. An instance of the abstract machine can thus have more than one possible execution for a given program and a given input

was hier auch zutrifft, ausgehend von dem Intervall möglicher Werte kann diese Variable nur X verschiedene Zustände annehmen.

Wobei du natürlich Recht hast, ich darf die Begriffe die ja explizit im Standard definiert und verwendet werden nicht mischen.

Trotzdem ist es doch für die Natur der Sprache unerheblich, ob bei einer Zuweisung a = b der rechte Operand einen unbestimmten Wert hat oder bspw. einen vom Programmierer zufällig ausgedachten. Er hat einen, also wird a auch einen haben.

[camper]

Sone schrieb:

ausgehend von dem Intervall möglicher Werte kann diese Variable nur X verschiedene Zustände annehmen.

Das mag so sein. Nur ist es eben nicht möglich, diesen Zustand (direkt - d.h. auslesen über l-zu-rvalue-Umwandlung) zu ermitteln.
Anders gesagt: Der Wert den ein Compiler in diesem Fall liefert, muss nichts mit dem tatsächlich am Ort der Variablen gespeicherten Wert (wie er sich aus den dort befindlichen Bytes ergeben würde) zu tun haben und er muss nat. auch nicht gleich bleiben, wenn man ihn ein Zweites mal liest. Klassisch undefiniertes Verhalten.

[Sone]

Der Wert den ein Compiler in diesem Fall liefert, muss nichts mit dem tatsächlich am Ort der Variablen gespeicherten Wert (wie er sich aus den dort befindlichen Bytes ergeben würde) zu tun haben und er muss nat. auch nicht gleich bleiben, wenn man ihn ein Zweites mal liest. Klassisch undefiniertes Verhalten.

Ahh... das heißt, bei jeder lvalue-to-rvalue Umwandlung wird ein undeterministischer Wert zurückgegeben? Ich habe es so verstanden, das die Variable einen unbestimmten aber festen Wert hat.

[facepalm]

Sone schrieb:

Ahh... das heißt, bei jeder lvalue-to-rvalue Umwandlung wird ein undeterministischer Wert zurückgegeben? Ich habe es so verstanden, das die Variable einen unbestimmten aber festen Wert hat.

Wozu die ganze Diskussion? Alles wurde schon mit dem dritten Post geklärt. Fettgedruckter Text: "Lvalue-to-rvalue conversion" "if the object is uninitialized" "undefined behavior". Schwer zu glauben, wie man das missverstehen kann. Ausser natürlich, du verstehst "undefined behaviour" nicht, dann frag aber bitte direkt nach.