Funktionsaufruf in C mit array type pointer

[Max (Gast)]

Hallo zusammen,

ich versuche inerhalb einer Funktion den Inhalt eines Arrays mit fester 
Länge das per typedef definiert wurde zu ändern. Hier das vereinfachte 
Problem:

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

typedef uint16_t AT_eightWords[8];

void Update(AT_eightWords * eW)
{
    eW[0] = 42;
    eW[1] = 43;
    eW[2] = 44;
    eW[3] = 45;
}

AT_eightWords GLOBAL_eW;

int main()
{
    printf("Hello World\n");
    
    Update(&GLOBAL_eW);
    
    printf("%d %d %d %d", GLOBAL_eW[0], GLOBAL_eW[1], GLOBAL_eW[2], GLOBAL_eW[3]);

    return 0;
}

Der Compiler meint zu "eW[0] = 42;":

error: assignment to expression with array type

Mit

    *eW[0] = 42;
    *eW[1] = 43;
    *eW[2] = 44;
    *eW[3] = 45;

meckert der Compiler nicht aber es ergibt sich die Ausgabe "42 0 0 0"

Wie geht es richtig?

[Walter T. (nicolas)]

Wenn Du auf die Zeigerschreibweise bestehst, wird es wohl auf ein

 *(eW+0) = 42;

hinauslaufen.

(Ehrlich gesagt wundert mich, dass Du bei Deiner Variante keinen 
Segmentation Fault einsammelst.)

[Max (Gast)]

Danke für die schnelle Antwort.
Zu:

    *(eW+0) = 42;
    *(eW+1) = 43;
    *(eW+2) = 44;
    *(eW+3) = 45;

meint der Compiler auch: "error: assignment to expression with array 
type"
(getestet mit https://www.onlinegdb.com/online_c_compiler)

[Oliver S. (oliverso)]

Stichwort operator precedence. [] sticht *

Daher:

(*eW)[0] = 42;

Oliver

[Walter T. (nicolas)]

Hoppla. Ja. Mein Fehler. Ich habe das ungewöhnliche Typedef übersehen. 
Hat das einen bestimmten Grund?

[Klaus W. (mfgkw)]

...
void Update(AT_eightWords eW)
...
Update(GLOBAL_eW);
...

[A. S. (Gast)]

Max schrieb:
> typedef uint16_t AT_eightWords[8];
> void Update(AT_eightWords * eW)

Das ist quasi ein Pointer auf ein Array, also ptr auf ptr.

Vermutlich willst Du nur ein Array, dann lass das * vor eW weg.

[Irgend W. (Firma: egal) (irgendwer)]

Walter T. schrieb:
> Ich habe das ungewöhnliche Typedef übersehen.
Der dürfte auch das problem sein. Das wäre dann ja quasi sowas hier und 
das passt nicht wirklich:

void Update(uint16_t[8] * eW)

So dürfte das eher hinkommen:

uint16_t GLOBAL_eW[8];
void Update(uint16_t *eW)
{
  eW[0] = 42;
  eW[1] = 43;
  eW[2] = 44;
  eW[3] = 45;
}
int main()
{
  Update(GLOBAL_eW);
...

oder wenn schon unbedingt typedef:

typedef uint16_t AT_eightWords;
AT_eightWords GLOBAL_eW[8];
void Update(AT_eightWords *eW)
{
  eW[0] = 42;
  eW[1] = 43;
  eW[2] = 44;
  eW[3] = 45;
}
int main()
{
  Update(GLOBAL_eW);
...

[Rolf M. (rmagnus)]

A. S. schrieb:
> Max schrieb:
>> typedef uint16_t AT_eightWords[8];
>> void Update(AT_eightWords * eW)
>
> Das ist quasi ein Pointer auf ein Array, also ptr auf ptr.

Ein Pointer auf ein Array ja, aber kein Pointer auf einen Pointer.

> Vermutlich willst Du nur ein Array, dann lass das * vor eW weg.

Generell würde ich typedefs für Arrays vermeiden, weil das nur 
Verwirrung stiftet.

Irgend W. schrieb:
> Das wäre dann ja quasi sowas hier und
> das passt nicht wirklich:
> void Update(uint16_t[8] * eW)

Genauer:

void Update(uint16_t (*eW)[8])

… ein Zeiger auf ein Array aus 8 chars.

[foobar (Gast)]

rmagnus schrieb:
> Generell würde ich typedefs für Arrays vermeiden, weil das nur
> Verwirrung stiftet.

In der Tat.  Eine Variable solchen Typs zu übergeben sieht aus wie ein 
"call by value" ist aber tatsächlich ein "call by reference".  D.h., 
ohne die Definition des Types zu kennen (die Definition der Variable 
reicht nicht!), kann man nicht erkennen, was der Code macht.

[Dirk B. (dirkb2)]

Rolf M. schrieb:
> Ein Pointer auf ein Array ja, aber kein Pointer auf einen Pointer.

In der Funktion dann aber schon.

[mh (Gast)]

Dirk B. schrieb:
> Rolf M. schrieb:
>> Ein Pointer auf ein Array ja, aber kein Pointer auf einen Pointer.
>
> In der Funktion dann aber schon.

Nein.

[Oliver S. (oliverso)]

Dirk B. schrieb:
> Rolf M. schrieb:
>> Ein Pointer auf ein Array ja, aber kein Pointer auf einen Pointer.
>
> In der Funktion dann aber schon.

void Update(AT_eightWords * eW)
{
  printf("%llu\n", sizeof(*eW));
}

Erst sagen, was da raus kommt, dann ausprobieren.

Oliver

[Florian K. (florian_k89)]

Ändere die Update(AT_eightWords *eW) zu
Zu Update(uint8_t *eW)
Dein Datentyp ist ein 8 Felder großes Array
davon machst du einen Pointer *eW und willst ihn so behandeln als wäre 
er ein einfacher Pointer. Ich denke das geht schief. In der Update () 
brauchst du eigentlich nur einen einfachen uint8_t Pointer.

[Philipp K. (philipp_k59)]

Max schrieb:
> *(eW+0) = 42;

Müsste das bei *eW+0 nicht mit void Update(AT_eightWords **eW) 
kombiniert werden?

Dann muss man aber die Klammern rausnehmen.

[A. S. (Gast)]

Oliver S. schrieb:
> Erst sagen, was da raus kommt, dann ausprobieren.

Die Größe des Arrays. Es ist aber egal, was da herauskommt.

Ein Array und ein Pointer sind bei einer Übergabe äquivalent.

Wenn der TO sich dessen klar wird, kann er auch herausklamüsern, was da 
passiert. Und ja, je nach Konstrukt was anderes. Beim TO

Max schrieb:
> *eW[0] = 42;
> *eW[1] = 43;
> *eW[2] = 44;
> *eW[3] = 45;

ist halt nur der erste Zugriff OK, der zweite zeigt auf Element 0 im 
Array dahinter (also nicht nächstes Element, sondern 8 Elemente, also 
außerhalb es eigentlichen Arrays.

Wenn er nicht nur "quasi" wie ich schrieb, sondern echt einen Ptr auf 
Ptr übergeben hätte, dann wäre auch der erste Zugriff OK, aber danach 
würde er die nächsten X Bytes als neuen Ptr interpretieren.

Egal. Den Mechnismus des TO habe ich erklärt, die Unterschiede zwischen 
Ptr und Array bei der Übergabe mögen Korinthen** unter sich ausmachen.

[Rolf M. (rmagnus)]

A. S. schrieb:
> Oliver S. schrieb:
>> Erst sagen, was da raus kommt, dann ausprobieren.
>
> Die Größe des Arrays. Es ist aber egal, was da herauskommt.

Das ist nicht egal. Wäre es ein Pointer auf einen Pointer, dann käme da 
eben nicht die Größe des Arrays raus.

> Ein Array und ein Pointer sind bei einer Übergabe äquivalent.

Naja, es kommt in der Funktion ein Pointer auf das erste Element an. Das 
Array "zefällt" zu einem Pointer. Aber das gilt nicht rekursiv. Ein 
Pointer auf ein Array bleibt auch nach Übergabe ein solcher und zerfällt 
nicht zu einem Pointer auf einen Pointer.

> Egal. Den Mechnismus des TO habe ich erklärt, die Unterschiede zwischen
> Ptr und Array bei der Übergabe mögen Korinthen** unter sich ausmachen.

Der ist hier allerdings für das Verständnis essenziell.

[A. S. (Gast)]

Rolf M. schrieb:
> Der ist hier allerdings für das Verständnis essenziell.

Um zu verstehen, was genau der Fehler macht. In beiden Fällen ist der 
Fehler fatal und die Wirkung gleich: Ein unbeteiligter Speicherbereich 
wird verwendet und führt zu undefiniertem Verhalten.

Ich habe natürlich auch überlegt, ob ich dabei schreiben sollte, wo er 
jetzt hingreift. Es hilft dem TO aber nicht beim Verständnis. Und die 
Diskussion, wann ein Array zu einem einzelnen Ptr zerfällt, ist hier 
sicher nicht dem TO angemessen. Anscheinend ja nichtmal den meisten 
Diskutanten.

[mh (Gast)]

A. S. schrieb:
> Und die
> Diskussion, wann ein Array zu einem einzelnen Ptr zerfällt, ist hier
> sicher nicht dem TO angemessen. Anscheinend ja nichtmal den meisten
> Diskutanten.

Dieses schrecklich komplizierte Konzept, das im Standard 3 ganze Zeilen 
belegt.

[A. S. (Gast)]

mh schrieb:
> Dieses schrecklich komplizierte Konzept, das im Standard 3 ganze Zeilen
> belegt.

Egal. Schau Dir den Thread hier an, wer da alles Probleme hat.

Oder schau Dir an, wie oft Du im Code sowas "int a[100]; ... foo(&a);" 
findest, also dass der Adressoperator auf ein Array gesetzt wird.

Wenn Du eine gute Erklärung hast, verlinke sie gerne. Aber hier ist es 
für den TO und andere mit ähnlicher Lernkurve schwer, noch was 
rauszuziehen.

[Al Fine (Gast)]

A. S. schrieb:
> Wenn Du eine gute Erklärung hast, verlinke sie gerne. Aber hier ist es
> für den TO und andere mit ähnlicher Lernkurve schwer, noch was
> rauszuziehen.

Harte Realiät: Der TO ist idR nach einiger Zeit meist nur noch ein 
Beispiel.

Die Info könnte doch für irgendwen nützlich sein.

[mh (Gast)]

A. S. schrieb:
> mh schrieb:
>> Dieses schrecklich komplizierte Konzept, das im Standard 3 ganze Zeilen
>> belegt.
>
> Egal. Schau Dir den Thread hier an, wer da alles Probleme hat.
>
> Oder schau Dir an, wie oft Du im Code sowas "int a[100]; ... foo(&a);"
> findest, also dass der Adressoperator auf ein Array gesetzt wird.

Bist du sicher, dass du damit keine Probleme hast? Oder was ist deiner 
Meinung nach das Problem in deinem Beispiel?

> Wenn Du eine gute Erklärung hast, verlinke sie gerne. Aber hier ist es
> für den TO und andere mit ähnlicher Lernkurve schwer, noch was
> rauszuziehen.
Der Standard, oder wenn man dazu nicht in der Lage ist, reicht 
https://en.cppreference.com/w/c/language/conversion. Das was auf der 
Seite steht, sollte man als C Entwickler kennen.

[A. S. (Gast)]

mh schrieb:
> Der Standard, oder wenn man dazu nicht in der Lage ist, reicht
> https://en.cppreference.com/w/c/language/conversion. Das was auf der
> Seite steht, sollte man als C Entwickler kennen.

Der Link ist jetzt Dein konstruktiver Beitrag hier im Thread? Und da 
soll der TO oder jemand anders erkennen, was bei

A. S. schrieb:
> int a[100]; ... foo(&a);"

falsch ist? Jedenfalls erwarte ich da foo(a) oder foo(&a[0]) oder von 
mir aus auch foo(a+0). Oder irgendwas anderes, was foo erwartet. Nur 
"&a" gibt (wenn foo eine Funktion ist) in keinem Fall Sinn.

Ja, Compiler akzeptieren das, doch trägt es zu der Verwirrung bei, der 
der TO in seinem Code erlegen war.

[mh (Gast)]

A. S. schrieb:
> Jedenfalls erwarte ich da foo(a) oder foo(&a[0]) oder von
> mir aus auch foo(a+0). Oder irgendwas anderes, was foo erwartet. Nur
> "&a" gibt (wenn foo eine Funktion ist) in keinem Fall Sinn.

foo(a), foo(&a[0]) und foo(a+0) sind offensichtlich falsch! Mein foo ist 
übrigens void foo(int (*a)[100]).

[Rolf M. (rmagnus)]

A. S. schrieb:
> a, Compiler akzeptieren das,

Wenn die Typen nicht passen, meldet das der Compiler eigentlich.