[C] Pointeroperationen in C

[Hador]

Hallo zusammen,
ich sitze hier gerade an einer Übung für meinen C-Kurs. Als Aufgabe haben wir ein paar Variablen gegeben und diverse Zuweisungen und sollen mit Begründung sagen warum das ganze nicht funktioniert. Zunächst einmal habe ich das ganze kurzerhand in ein Programm geschrieben und durch den Compiler gejagt um zu sehen, was geht und was nicht. Einiges kann ich mir auch erklären, jedoch sind mir ein paar Stellen noch schleierhaft. In der Hoffung, das sich hier auch ein paar C-Programmierer tummeln:

Code:

[...]
int main(void) {
   int feld[1];
   int i;
   int *p;
   int *p1;
   int *p2;

   p = feld; /* Funktioniert, da feld ein Pointer auf das erste Arrayelement ist und es sich um ein Integerarray handelt */
   /* feld = p; */ /* Funktioniert nicht, da p nicht zwangsläufig auf ein Integerarray zeigt (Aber auf einen int und das wäre ja das selbe, wie ein einelementiges Array, oder?) */

   p = &feld[3]; /* der &-Operator liefert einen Pointer auf das vierte Arrayelement zurück */
   feld[2] = p[5]; /* p[5] liefert den um fünf mal Integergröße veschobenen Pointer zurück */

   p1 = p2 + i; /* Der Zeiger wird um einen Integerwert verschoben */
   p1 = i + p2; /* Auch hier wird der Zeiger verschoben */

   /* Bei folgenden Zuweisungen bin ich mir recht unsicher: */
   /* i = p1 * p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */
   i = p1 - p2; /* Wieso ist - denn für zwei Pointer definiert? */
   /* i = p1 + p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */

   [...]
}

Ich habe meine Erklärungen bzw. Fragen mal hinter die jeweiligen Zuweisungen geschrieben und hoffe, dass ihr mir etwas weiterhelfen könnt.

Gruß Lars

[Apollonius]

Ich vermute, dass der C-Compiler ein int[1] als statisches Array implementiert, d.h. auf dem Stack ablegt. Um zu dynamischen Arrays, also int[], kompatibel zu bleiben, erlaubt er p = feld weiterhin und interpretiert es als Abkürzung für p = &feld[0]. feld = p funktioniert aber nicht, weil feld als statisches Array eine feste Adresse hat. Dies ist jedoch nur Spekulation! Ich habe es nicht getestet.

Das es einen "int operator-(void*, void*)" gibt, ist absolut sinnvoll. Er dient dazu, den Abstand zwischen zwei Adressen herauszufinden. Das ist beispielsweise nützlich, um einen Jump-Offset zu berechnen.

[bigg]

Werte in C nicht zu initialisieren kann tödlich sein. Außerdem sollte man beachten, wie man seine Variablen alloziiert. Heap und Stack sagen dir etwas? Zudem kann man Variablen auch in der Versenkung verschwinden lassen, wenn man einfach deren Adressen überschreibt. Lass dir zur Sicherheit deren Werte und Adressen anzeigen. Mit sprintf() müsste es in C funktionieren, aber ich denke du verwendest eh einen C++ Compiler von daher ist ein einfaches

Code:

cout << &i;

(nicht C konform) ausreichend, aber zum debuggen alle mal besser.

[Hador]

Zitat:

Zitat von Apollonius

Ich vermute, dass der C-Compiler ein int[1] als statisches Array implementiert, d.h. auf dem Stack ablegt. Um zu dynamischen Arrays, also int[], kompatibel zu bleiben, erlaubt er p = feld weiterhin und interpretiert es als Abkürzung für p = &feld[0]. feld = p funktioniert aber nicht, weil feld als statisches Array eine feste Adresse hat. Dies ist jedoch nur Spekulation! Ich habe es nicht getestet.

Dynamische Arrays gibt es im C90 nur insoweit, dass man etwas sowas schreiben kann: int[] = {1, 2, 3}. Wirklich dynamisch ist das nicht. Aber ich werde da mal ein wenig weiterprobieren.

Zitat:

Zitat von Apollonius

Das es einen "int operator-(void*, void*)" gibt, ist absolut sinnvoll. Er dient dazu, den Abstand zwischen zwei Adressen herauszufinden. Das ist beispielsweise nützlich, um einen Jump-Offset zu berechnen.

Jo, ergibt Sinn, daran hatte ich nicht gedacht.

Zitat:

Zitat von bigg

Werte in C nicht zu initialisieren kann tödlich sein. Außerdem sollte man beachten, wie man seine Variablen alloziiert. Heap und Stack sagen dir etwas? Zudem kann man Variablen auch in der Versenkung verschwinden lassen, wenn man einfach deren Adressen überschreibt. Lass dir zur Sicherheit deren Werte und Adressen anzeigen. Mit sprintf() müsste es in C funktionieren, aber ich denke du verwendest eh einen C++ Compiler von daher ist ein einfaches

Code:

cout << &i;

(nicht C konform), aber zum debuggen alle mal besser.

Es geht nicht um ein reales Programm, sondern eine Übung und damit um die Frage, welche Zuweisungen warum funktionieren. Ansonsten werden natürlich Variablen initialisiert :wink:
Mit sprintf() kann man in Strings herumschreiben. Was du vermtulich meinst ist einfach printf().
Übrigends wird strikt bach ISO C90 gecoded. Da ist nix mit C++.

[Fridolin Walther]

Zitat:

Zitat von Hador

Zitat:

Zitat von Apollonius

Ich vermute, dass der C-Compiler ein int[1] als statisches Array implementiert, d.h. auf dem Stack ablegt. Um zu dynamischen Arrays, also int[], kompatibel zu bleiben, erlaubt er p = feld weiterhin und interpretiert es als Abkürzung für p = &feld[0]. feld = p funktioniert aber nicht, weil feld als statisches Array eine feste Adresse hat. Dies ist jedoch nur Spekulation! Ich habe es nicht getestet.

Dynamische Arrays gibt es im C90 nur insoweit, dass man etwas sowas schreiben kann: int[] = {1, 2, 3}. Wirklich dynamisch ist das nicht. Aber ich werde da mal ein wenig weiterprobieren.

In C99 waren die Leute die die Spec verfasst haben auf Drogen und erlauben dynamische Arrays auf dem Stack. Also z.B. sowas hier:

Code:

int function(int i)
{
  int intarray[i];
  [...]
}

Der erzeugte Code gleicht in fast allen Fällen einem alloca, wobei alloca in fast allen Implementierungen (der Microsoft Compiler ist da die einzige mir bekannte Ausnahme) schlecht implementiert ist (eine einfache Stack Pointer Modifikation ohne irgendwelche Checks). Wenn Du es schaffst i von aussen zu beeinflussen, hast Du als "Angreifer" also volle Kontrolle über den Stackpointer und das ist im Normalfall keine sonderlich gute Idee.

[Apollonius]

Da bin ich tatsächlich von C++ und Java ausgegangen, in denen man ein int[] ohne Initialisierungsliste deklarieren kann. Insofern erübrigt sich in C die Unterscheidung statisches/dynamisches Array.

Zitat:

Code:

p1 = p2 + i; /* Der Zeiger wird um einen Integerwert verschoben */

Soweit ich weiß, heißt das nicht p1 = (void*)((int)p2 + i), sondern p1 = (void*)((int)p2 + 4*i).

@0xF30FC7: Das ist tatsächlich grausig. Eine vernünftige Implementation sollte das als int* intarray = malloc(4*i) behandeln.

[Der Jan]

Zitat:

Zitat von Hador

Code:

   feld[2] = p[5]; /* p[5] liefert den um fünf mal Integergröße veschobenen Pointer zurück */

Ähm nicht ganz :) p[5] liefert das Feldelement mit dem Index 5, also das 6te Element zurück, allerdings ist der Ausdruck falsch, wenn auch syntaktisch richtig. feld[2] -> hier kann es dier ganz schnell mal ne AV raushauen, schau dir mal die Definition von feld an.

Edit: Vielleicht solltest du die Frage auch mal im CPP-Forum stellen, dort tummeln sich die C/C++ Experten

[Apollonius]

Doch, Hador hat recht. p[5] = *((int*)((int)p + 5*4))

[Dax]

Zitat:

Zitat von Apollonius

Doch, Hador hat recht. p[5] = (p + 5*4)*

Das ist doch "Element an Stelle 6"? Verschoben um 5 ints wäre doch p + 20..?

[Der Jan]

Zitat:

Zitat von Apollonius

Doch, Hador hat recht. p[5] = (p + 5*4)*

Und der letzte Stern? :)

Auch wenn es p+5*sizeof(int) heißen müsste :)

Edit: Dax, du warst schneller :)

[Der Jan]

Zitat:

Zitat von Hador

Code:

   
   /* i = p1 + p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */

   [...]
}

Das würde auch gehen, wenn du p2 vorher nach int castest, allerdings ein Sinn dafür fällt mir aktuell nicht ein.

[Hador]

Zitat:

Zitat von Der Jan

Ähm nicht ganz :) p[5] liefert das Feldelement mit dem Index 5, also das 6te Element zurück, allerdings ist der Ausdruck falsch, wenn auch syntaktisch richtig. feld[2] -> hier kann es dier ganz schnell mal ne AV raushauen, schau dir mal die Definition von feld an.

Der Pointer zeigt doch schon auf das erste Element und wenn ich ihn dann um fünf Elemente verschiebe zeigt er auf das Sechste :gruebel:
Aber ich werde es noch mal etwas deutlischer aufschreiben.

Zitat:

Zitat von Der Jan

Edit: Vielleicht solltest du die Frage auch mal im CPP-Forum stellen, dort tummeln sich die C/C++ Experten

Jo, mal sehen. Sollte ich öfters Fragen in diese Richtung haben, so werde ich das auch wohl machen, aber für einmal wollte ich micht nicht noch extra irgendwo anmelden.

Zitat:

Zitat von Der Jan

Zitat:

Zitat von Hador

Code:

   
   /* i = p1 + p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */

Das würde auch gehen, wenn du p2 vorher nach int castest, allerdings ein Sinn dafür fällt mir aktuell nicht ein.

Casten ist nicht. Die Zuweisungen sind gegeben. Sonst würde man ja auch alles irgendwie durch den Compiler bekommen :mrgreen:

[Flocke]

Code:

int main(void) {
   int feld[1];
   int i;
   int *p;
   int *p1;
   int *p2;

   p = feld; /* Funktioniert, da feld ein Pointer auf das erste Arrayelement ist und es sich um ein Integerarray handelt */

Dein Kommentar ist korrekt.

Code:

   /* feld = p; */ /* Funktioniert nicht, da p nicht zwangsläufig auf ein Integerarray zeigt (Aber auf einen int und das wäre ja das selbe, wie ein einelementiges Array, oder?) */

Funktioniert nicht, weil "feld" als Symbol einen konstanten Wert hat (also kein L-Wert ist).

Code:

   p = &feld[3]; /* der &-Operator liefert einen Pointer auf das vierte Arrayelement zurück */

Der &-Operator liefert die Adresse eines Ausdrucks, und feld[3] ist das vierte Array-Element. Somit ist deine Aussage korrekt.

Code:

   feld[2] = p[5]; /* p[5] liefert den um fünf mal Integergröße veschobenen Pointer zurück */

Die Indizierung eines Zeigers basiert in C immer auf der Größe des Datentyps, auf den der Zeiger zeigt. Bei einem "int*" werden jeweils "int"-Element indiziert. "p[5]" liefert keinen Zeiger zurück, sondern direkt den Wert des 6ten Elements des Arrays, auf das p zeigt.

Code:

   p1 = p2 + i; /* Der Zeiger wird um einen Integerwert verschoben */

Deine Aussage ist korrekt.
Auch hier gilt die Aussage von oben: die Addition einer Zahl zu einem Zeiger basiert auf der Größe des Datentyps, auf den der Zeiger zeigt. Somit ist "p[5]" von oben gleichwertig mit "*(p + 5)".

Code:

   p1 = i + p2; /* Auch hier wird der Zeiger verschoben */

Deine Aussage ist korrekt.

Code:

   /* Bei folgenden Zuweisungen bin ich mir recht unsicher: */
   /* i = p1 * p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */

Deine Aussage ist korrekt.

Code:

   i = p1 - p2; /* Wieso ist - denn für zwei Pointer definiert? */

Genauso wie die Addition eines Zeigers und eines Integer-Wertes wieder einen Zeiger liefert, liefert die Subtraktion zweier Zeiger einen Integer-Wert: nämlich den, den du zum zweiten Zeiger hinzuzählen müsstest um den ersten Zeiger zu erhalten. Beispiel:

Code:

p = &feld[3];
i = p - feld; // i hat jetzt den Wert 3

p1 = &feld[3];
p2 = &feld[5];
i = p2 - p1;  // i hat jetzt den Wert 2

p1 = feld + 3;
p2 = p1 + 4;
i = p2 - p1;  // i hat jetzt den Wert 4

Code:

   /* i = p1 + p2; */ /* Funktioniert nicht, da der *-Operator nicht für zwei Pointer definiert ist */

Die Addition ist für zwei Zeiger nicht definiert.

[Apollonius]

Wir haben hier klassich aneinander vorbei geredet. Ich dachte, die Aussage

Zitat:

p[5] liefert das Feldelement mit dem Index 5, also das 6te Element zurück

bezöge sich auf einen falschen Index. Anscheinend bezog sie sich aber darauf, dass der Array-Indizierungs-Operator gleichzeitig auch dereferenziert.

[Macci]

Zitat:

Zitat von Apollonius

Doch, Hador hat recht. p[5] = *((int*)((int)p + 5*4))

So ist das aber Quatsch (p kann nicht als int-Wert gecastet werden).

Es geht doch ganz einfach:

Code:

p[5] == *(p+5)

Viele Grüsse,
Macci

[Der Jan]

Zitat:

Zitat von Hador

Zitat:

Zitat von Der Jan

Ähm nicht ganz :) p[5] liefert das Feldelement mit dem Index 5, also das 6te Element zurück, allerdings ist der Ausdruck falsch, wenn auch syntaktisch richtig. feld[2] -> hier kann es dier ganz schnell mal ne AV raushauen, schau dir mal die Definition von feld an.

Der Pointer zeigt doch schon auf das erste Element und wenn ich ihn dann um fünf Elemente verschiebe zeigt er auf das Sechste :gruebel:
Aber ich werde es noch mal etwas deutlischer aufschreiben.

Es wird hier aber kein Pointer irgendwohin verschoben, nicht ein Stückchen ! Mit "p[n]" bekommst du das n-te Element des Feldes zurück, in deinem Fall ein int, und keinen Pointer, wie nun schon mehrfach erwähnt.....

[Der Jan]

Zitat:

Zitat von Macci

Zitat:

Zitat von Apollonius

Doch, Hador hat recht. p[5] = *((int*)((int)p + 5*4))

So ist das aber Quatsch (p kann nicht als int-Wert gecastet werden).

Es geht doch ganz einfach:

Code:

p[5] == *(p+5)

Viele Grüsse,
Macci

Es wird langsam echt abenteuerlich hier :)

@Appolonius: Nix für ungut, aber akzeptier doch einfach, was p[n] bedeutet, anstatt immer wildere Casts zu entwerfen. :)

@Macci: Mann kann p als int casten, auch wenn der Sinn des Ganzen gegen Null geht und nein, es ist kein Wortspiel, ich meine nicht NULL.

"*4" --> Augen auf! Nicht auf jedem System ist sizeof(int) == 4

[Macci]

Zitat:

Zitat von Der Jan

@Macci: Mann kann p als int casten, auch wenn der Sinn des Ganzen gegen Null geht und nein, es ist kein Wortspiel, ich meine nicht NULL.

Nein, im Allgemeinen wird das nicht funktionieren. Nur auf manchen Maschinen und nur unter manchen Übersetzern kann ein Zeiger als int-Wert gecastet werden. (siehe im Standardwerk "Programmieren in C", Kap. 5.6 "Zeiger sind keine ganzzahligen Werte", S. 111).

Edit: Auf "manchen" ist untertrieben, es funktioniert schon auf den meisten (nicht jedoch auf allen). Aber es ist ganz schlechter Programmierstil.

Viele Grüsse,
Macci

[Der Jan]

@Macci: Ok, ich muß halt noch einen nachlegen (nicht persönlich nehmen).... Theorie und Praxis, das kennt man ja. Egal, was in dem Standardwerk auf Seite 4711 geschrieben steht, ich habe noch kein System erlebt, auf dem es nicht ging, denn, auch wenn die Theorie was anderes sagt, ist in der Praxis ein Pointer eine Adresse, welche nichts anderes ist, als ein xx-bit-Integer.

Aber, wie schon erwähnt, der Sinn des ganzen Rumgecastes geht in diesem Fall gegen Null (nicht NULL) :)