C Progr.. warum Klammern

[p_mork]

In diesem Beispiel ist TestData jedoch ein Array und das & macht rein garnichts.

Das stimmt nicht. In allen Beispielen wird die Adresse von TestData zugewiesen, aber in diesem Fall, die Adresse von der Adresse, also entsteht ein Doppelzeiger vom Typ unsigned char**.

Worauf soll &TestData denn zeigen??

Es gibt keine Adresse von Adresse von TestData, da die Adresse von TestData ein rvalue ist und deshalb nicht weiter referenziert werden kann. Der Adress-Operator & macht bei Arrays nichts. Wäre TestArray ein unsigned char* dann würde der Typ von &TestData tatsächlich unsigned char** sein und &TestData würde auf die Adresse von diesem Zeiger ergeben.

MfG Mark

[Siro]

Hallo zusammen,
da muss ich jetzt dem PicNick absolut zustimmen.
Solange ich keine Operation mit dem Zeiger ausführe, ist es völlig unerheblich wie ich diesen Pointer caste. Es wird lediglich festgelegt, auf welche Adresse der Pointer zeigen soll. Ob das ein Char, Int, Array oder was auch immer ist, spielt für den Compiler erstmal keine Rolle. Das "casten" macht so gesehen erstmal überhaupt keinen Sinn und könnte auch Weggelassen werden. Wenn ich aber möchte, daß der "universelle Pointer "VOID" welcher ja zunächst Typenlos ist um ein oder 2 oder 4 Bytes nach der Operation erhöht wird. muss ich ihm natürlich mitteilen
um welchen Datentyp es sich handelt, erst ab da gibt das "Casting" überhaupt einen Sinn.

Wobei ich mir grad selber, beim Schreiben dieses Textes unsicher werde...
wie ist es denn mit "Little Endian" und "Big Endian" ? Zeigt der Pointer dann stets auf das erste Byte ? Dann könnte dies das MSB oder auch das LSB sein. Nehmen wir mal an, ich habe eine 16 Bit Variable. In Intel Notation (Little endian) steht dann das Low Byte z.B. bei Adresse 1000, dann steht das High Byte bei 1001. In Motorola Notation steht dann das High Byte bei 1000 und das Low Byte bei 1001. Wenn ich nun einen Pointer auf diese Variable setze, wo zeigt er dann eigentlich hin ??
Wenn ich nun einen Typecast auf das adressierte Byte mache, und um eins erhöhe, könnte das +1 oder +256 sein.

Ist mir jetzt zu schwierig, muss ich mal drüber schlafen....


muss mich eben revidieren:
zu PicNick

Habe eben nochmal simuliert:

n = (void*) TestData; /* angeblich inhalt Testdata, laut PicNick */
n = (void*) &TestData; /* adresse TestData */

in beiden Fällen wird n auf die Adresse von Testdata gesetzt.

wenn ich nichts falsch gemacht habe....

Siro

[PicNick]

Meine Behauptung wird nur stimmen, wenn "TestData" KEIN array ist
Little / Big Endian:
Ein Pointer zeigt immer auf das erste memory-Byte.
Es ist nur immer der Aufbau des Pointer und die Bearbeitung der Daten entsprechend.

[oberallgeier]

... Es ist nur immer der Aufbau des Pointer und die Bearbeitung der Daten entsprechend ...

Das eine oder andere hier verstehe ich ja oder kann es nacharbeiten. Aber der Thread gibt mir mehr und mehr die Zuversicht, dass ich C praktisch garnicht kann. Zumindest über weite Strecken. Immerhin scheinen jede Menge bisher unbenützter Seiten in meinem Kernighan/Ritchie doch nicht für die Tonne zu sein.

Aber eins ist auch klar: Schuld sind die Engländer, die nicht nur auf der falschen Seite autofahren, sondern auch die Eier am dünnen Ende aufknicken - und das noch aus Glaubensgründen.

[Felix G]

Hier mal ein kleiner Auszug aus dem C99-Standard

6.5.3.2 Address and indirection operators
Constraints
1 The operand of the unary & operator shall be either a function designator, the result of a
[] or unary * operator, or an lvalue that designates an object that is not a bit-field and is
not declared with the register storage-class specifier.

2 The operand of the unary * operator shall have pointer type.

Semantics
3 The unary & operator yields the address of its operand. If the operand has type ‘‘type’’,
the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator,
neither that operator nor the & operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an
lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor
the unary * that is implied by the [] is evaluated and the result is as if the & operator
were removed and the [] operator were changed to a + operator. Otherwise, the result is
a pointer to the object or function designated by its operand.

4 The unary * operator denotes indirection. If the operand points to a function, the result is
a function designator; if it points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type ‘‘type’’. If an
invalid value has been assigned to the pointer, the behavior of the unary * operator is
undefined.

Da steht viel, aber eben nicht, daß sich der & Operator bei einem Array anders verhalten sollte als bei einem normalen Pointer. Das mag zwar bei den meisten Compilern so sein, aber es steht eben nicht im Standard (oder wenn, habe ich die entsprechende Stelle übersehen). Wenn man also in seinem Programm davon ausgeht, daß "ArrayName" und "&ArrayName" den selben Wert liefern, funktioniert es vielleicht nicht mehr wenn man auf einen anderen Compiler umsteigt.

[Siro]

PicNick schrieb:

Meine Behauptung wird nur stimmen, wenn "TestData" KEIN array ist

Da muss ich ihm vollkommen zustimmen, ich habe es eben mit dem IAR Compiler getestet,
mit folgenden verblüffenden Resultaten:

• --------------------------------------------------------------
  wenn TestData ein Array ist: unsigned char TestData[4];
  
  n = (void*) TestData; /* Adresse TestData */
  n = (void*) TestData[0]; /* Inhalt Testdata */
  n = (void*) &TestData; /* Adresse TestData */
  n = (void*) *&TestData; /* Adresse TestData */
  
  --------------------------------------------------------------
  wenn TestData kein Array ist: unsigned char TestData;
  
  n = (void*) TestData; /* Inhalt TestData */
  n = (void*) TestData[0]; /* geht natürlich nicht */
  n = (void*) &TestData; /* Adresse TestData */
  n = (void*) *&TestData; /* Inhalt TestData */
  --------------------------------------------------------------

Siro

[PicNick]

Bei sowas
++(*((char**)(&n)));
glaub ich halt immer, jemand hat die Tastatur mit dem Scheuerbesen abgewischt.
Das ist imho reiner Schamanismus.
Andere Meinungen sind aber durchaus zulässig, ich wollt' es nur gesagt haben.

[p_mork]

Hier mal ein kleiner Auszug aus dem C99-Standard

6.5.3.2 Address and indirection operators
Constraints
1 The operand of the unary & operator shall be either a function designator, the result of a
[] or unary * operator, or an lvalue that designates an object that is not a bit-field and is
not declared with the register storage-class specifier.

2 The operand of the unary * operator shall have pointer type.

Semantics
3 The unary & operator yields the address of its operand. If the operand has type ‘‘type’’,
the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator,
neither that operator nor the & operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an
lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor
the unary * that is implied by the [] is evaluated and the result is as if the & operator
were removed and the [] operator were changed to a + operator. Otherwise, the result is
a pointer to the object or function designated by its operand.

4 The unary * operator denotes indirection. If the operand points to a function, the result is
a function designator; if it points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type ‘‘type’’. If an
invalid value has been assigned to the pointer, the behavior of the unary * operator is
undefined.

Da steht viel, aber eben nicht, daß sich der & Operator bei einem Array anders verhalten sollte als bei einem normalen Pointer. Das mag zwar bei den meisten Compilern so sein, aber es steht eben nicht im Standard (oder wenn, habe ich die entsprechende Stelle übersehen). Wenn man also in seinem Programm davon ausgeht, daß "ArrayName" und "&ArrayName" den selben Wert liefern, funktioniert es vielleicht nicht mehr wenn man auf einen anderen Compiler umsteigt.

Ok, ich geb mich geschlagen. Du hast also Recht. Hab gerade auch etwas rumgesucht und erfahren, dass ein Array sehr wohl ein lvalue ist, was alles, was ich oben gesagt habe, zunichte macht.

MfG Mark