Zeiger auf Array?

[Michl (Gast)]

Ja, ich dachte bisher ich habe Zeiger und Arrays verstanden.
Doch jetzt komm ich grad an einen Punkt wo ich an mir zweifle.

Ich habe ein lokales Array:

uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};

Nun will ich eine Funktion schreiben die so ein Array entgegennimmt und 
zwei Aufgaben hat:
1) irgendwas aus den Werten berechnen, das ist ja trivial
2) als Nebeneffekt: das Array inkrementieren, damit ein zweiter Call zu 
dieser Funktion ein anderes Ergebnis liefert

void doSomething(uint8_t *ptr);

Eine Solche Funktion erfüllt Kriterium 1). Ich kann ihr mein Array 
übergeben. Der Name des Arrays "decayed" dabei zu einem Zeiger aufs 
erste Element, also zu

&(myArray[0])

. doSomething() kann also auf Array-Elemente zugreifen und damit was 
berechnen.
Allerdings: eine solche Funktion kann das Array nicht "weiterzählen".

void doSomething(uint8_t *ptr)
{
    ...berechnung...
  
  ptr++;
}

macht natürlich nicht das was ich will, ptr++ zählt ja nur die lokale 
Kopie hoch, die nach dem return eh verloren ist.

Ich muss also meinen Zeiger-auf-Array by-reference übergeben, meine 
Funktion müsste also so aussehen:

void doSomething(uint8_t *ptr[]);

Der Aufruf geschieht dann so:

doSomething(&myArray);

void doSomething(uint8_t *ptr)
{
    ...berechnung...
  
  (*ptr)++;
}

So kann ich dann den Zeiger des Callers derart manipulieren dass er beim 
nächsten Aufruf auf andere Daten operiert.

Soweit die Theorie:
Unter Win7_x64 hat das Ganze einen Absturz zufolge, ich denke mal unter 
Linux hätt ich hier die Ausgabe: Segmentation Fault.

Wo liegt denn da mein Denkfehler?
Wie kann ich es erreichen dass eine Helferfunktion den lokalen Zeiger 
des Callers inkrementiert?

[Peter II (Gast)]

da sollte funktionieren.

Zeige uns ein Beispiel was vollständig ist.

[Stefan (Gast)]

void doSomething(uint8_t **ptr)

der Parameter der Funktion sollte auch stimmen, sonst gibts murks.

[A. H. (ah8)]

myArray ist eine Konstante, die auf eine bestimmte Adresse im Speicher 
zeigt, die kannst du gar nicht hoch zählen. Mich wundert, dass &myArray 
geht; da Konstanten ja keinen Speicherplatz belegen können sie auch 
keine Adresse haben. (Es kann aber sein, dass wegen der Pointer/Array 
Äquivalenz in diesem Fall &myArray=myArray gilt, habe ich jetzt nicht 
geprüft.)

Du brauchst so etwas:

uint8_t *pMyArray = myArray;

Den Pointer kannst Du hoch zählen und der hat auch eine Adresse.

PS: Woher weiß Deine Funktion, wie lang das Restfeld noch ist?

[Rolf Magnus (Gast)]

Michl schrieb:
> Nun will ich eine Funktion schreiben die so ein Array entgegennimmt und
> zwei Aufgaben hat:
> 1) irgendwas aus den Werten berechnen, das ist ja trivial
> 2) als Nebeneffekt: das Array inkrementieren, damit ein zweiter Call zu
> dieser Funktion ein anderes Ergebnis liefert

"das Array inkrementieren" ergibt keinen Sinn. Ein Array kann man nicht 
inkrementieren.

> Allerdings: eine solche Funktion kann das Array nicht
> "weiterzählen".void doSomething(uint8_t *ptr)
> {
>     ...berechnung...
>
>   ptr++;
> }

Ah, du möchtest also nicht ein Array, sondern einen Zeiger 
inkrementieren.

> macht natürlich nicht das was ich will, ptr++ zählt ja nur die lokale
> Kopie hoch, die nach dem return eh verloren ist.

Richtig.

> Ich muss also meinen Zeiger-auf-Array by-reference übergeben, meine
> Funktion müsste also so aussehen:
> void doSomething(uint8_t *ptr[]);

Auch richtig. Du kansnt auch schreiben:

void doSomething(uint8_t **ptr);

>
> Der Aufruf geschieht dann so:
> doSomething(&myArray);

> Wo liegt denn da mein Denkfehler?

myArray ist ein Array. &myArray ist ein Zeiger auf ein Array. Du mußt 
aber einen Zeiger auf einen Zeiger übergeben, nicht auf ein Array.

> Wie kann ich es erreichen dass eine Helferfunktion den lokalen Zeiger
> des Callers inkrementiert?

Es würde schon mal helfen, wenn dieser lokale Zeiger überhaupt 
existieren würde. ;-)

uint8_t * p = myArray;
doSomething(&p);

[Michl (Gast)]

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

void doSomething(uint8_t *buf[])
{
  uint8_t local;

  local = *buf[0];

  printf("%x\n", local);

    (*buf)++;
}

int main(void)
{
    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};

    doSomething(&myArray);
    doSomething(&myArray);

    return 0;
}

Sorry, hier ein komplettes Beispiel.
Was ich herausgefunden habe:
Nicht das Inkrementieren verursacht den Absturz, sondern die Zeile 
local = *buf[0];
Aber wieso? Ich muss doch den Zeiger doppelt dereferenzieren, einmal 
durch den *-Operator, einmal durch [].

[Karl H. (kbuchegg)]

Michl schrieb:

Definiere erst mal, was das hier

> 2) als Nebeneffekt: das Array inkrementieren

bedeuten soll.

Was soll 'das Array inkrementieren' für eine Operation sein? Was soll 
die bewirken? Beschreib das doch mal näher (ja, ja ich weiß schon. Beim 
nächsten Aufrf soll mit anderen Daten operiert werden. Aber wo sind denn 
diese anderen Daten?)

[Rolf Magnus (Gast)]

Michl schrieb:
> Nicht das Inkrementieren verursacht den Absturz, sondern die Zeile
> local = *buf[0];
> Aber wieso?

Du übergibst die Adresse von myArray. Wenn du die dereferenzierst, 
kommst du auf das erste Element des Arrays. Jetzt dereferenzierst du 
nochmal, wodurch dieses erste Element (und noch ein paar folgende) als 
Adresse interpretiert wird, und dann versucht das Programm, von dieser 
Adresse zu lesen, wobei natürlich dann Blödsinn rauskommt.

[Michl (Gast)]

Nachtrag:
folgender Code tut genau das was ich will, sogar ohne Warnungen:

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

void doSomething(uint8_t *buf[])
{
  uint8_t local;

  local = *buf[0];

  printf("%x\n", local);

    (*buf)++;
}


void help(uint8_t *buf)
{
  doSomething(&buf);
  doSomething(&buf);
}


int main(void)
{
    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};

    help(myArray);

    return 0;
}

Durch den Umweg über die help-Funktion geht in doSomething() die Info 
verloren dass da irgendwo ein Array dahinter liegt.
Ich denke mal das ist das Problem, da man, wie Rolf Magnus und KH 
Buchegger anmerkten, ein Array nicht inkrementieren kann. Der Umweg über 
help() ist ja letzendlich gleichwertig mit der von Rolf Magnus 
vorgeschlagenen Lösung, den lokalen Pointer anzulegen.

[Michl (Gast)]

Karl Heinz schrieb:
> Was soll 'das Array inkrementieren' für eine Operation sein? Was soll
> die bewirken? Beschreib das doch mal näher (ja, ja ich weiß schon. Beim
> nächsten Aufrf soll mit anderen Daten operiert werden. Aber wo sind denn
> diese anderen Daten?)

Das dient dazu, aus einem Bytestrom einige Bytes herauszulesen. Immer 
Häppchenweise, und diese zu verarbeiten.

[Karl H. (kbuchegg)]

Michl schrieb:

> Sorry, hier ein komplettes Beispiel.

Dieses Beispiel ergibt keinen Sinn.

Das hier

void doSomething(uint8_t *buf[])

besagt, dass buf ein Array von Pointer ist, wobei jeder Pointer auf 
(mindestens) einen uint8_t zeigt.

Hier hast du also vereinbart, dass buf diese Gestalt hat

  buf
  +------+                    +---+---+---+---+---+
  |  o----------------------->| 3 | 8 | 5 | 2 | 4 |
  +------+                    +---+---+---+---+---+
  |  o------------+
  +------+        |    +---+---+
  |  o-------+    +--->| 2 | 8 |
  +------+   |         +---+---+
  |  o-----+ |
  +------+ | |
           | +-----> ....
           |
         ....

Nur: Deine Daten sehen nicht so aus!
Das hier

    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};

ist etwas völlig anderes und auch wenn du mittels eines Adressoperators 
erst mal alles ruhig gestellt hast, ändert das nichts an der Tatsache, 
dass deine Daten nicht den Aufbau haben, den die Funktion voraussetzt.
Du kannst eine Kuh weiß anstreichen, aber das macht sie nicht zum 
Schimmel.

[Karl H. (kbuchegg)]

Michl schrieb:
> Karl Heinz schrieb:
>> Was soll 'das Array inkrementieren' für eine Operation sein? Was soll
>> die bewirken? Beschreib das doch mal näher (ja, ja ich weiß schon. Beim
>> nächsten Aufrf soll mit anderen Daten operiert werden. Aber wo sind denn
>> diese anderen Daten?)
>
> Das dient dazu, aus einem Bytestrom einige Bytes herauszulesen. Immer
> Häppchenweise, und diese zu verarbeiten.

Schön.
Aber wo sind diese Daten in deinem Programm.
Wenn du sagst, du willst ein anderes Array benutzen (und das tust du mit 
deinem Code), dann muss es auch ein anderes Array geben. Wo ist dieses?

[A. H. (ah8)]

Michl schrieb:
> Was ich herausgefunden habe:
> Nicht das Inkrementieren verursacht den Absturz, sondern die Zeile
> local = *buf[0];
> Aber wieso? Ich muss doch den Zeiger doppelt dereferenzieren, einmal
> durch den *-Operator, einmal durch [].

Der []-Operator hat eine höhere Priorität, als der *-Operator. Folglich 
ist

uint8_t *buf[]

nicht ein pointer auf ein Array, sondern ein Array von Pointern (auf 
uint8_t). Wenn, dann muss es so heißen:

uint8_t (*buf)[]

Gleiches gilt für die Dereferenzierung

local = (*buf)[0];

[Karl H. (kbuchegg)]

Michl schrieb:
> Nachtrag:
> folgender Code tut genau das was ich will

Ist aber immer noch Quatsch.

> sogar ohne Warnungen:

Das heisst nicht viel.

[Michl (Gast)]

Naja ich will eigentlich kein anderes Array verwenden.
myArray enthält den Datenstrom, den ich auswerten will.

Immer häppchenweise. Beim ersten mal eben das 0x00 in meinem Beipsiel, 
danach 0x01, 0x02, usw.

[Karl H. (kbuchegg)]

A. H. schrieb:
> Michl schrieb:
>> Was ich herausgefunden habe:
>> Nicht das Inkrementieren verursacht den Absturz, sondern die Zeile
>> local = *buf[0];
>> Aber wieso? Ich muss doch den Zeiger doppelt dereferenzieren, einmal
>> durch den *-Operator, einmal durch [].
>
> Der []-Operator hat eine höhere Priorität, als der *-Operator. Folglich
> ist

Hier kommt eher die Rechts-Links Regel zur Anwendung

http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

[Peter II (Gast)]

müsste doch so gehen

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

void doSomething(uint8_t *buf )
{
  uint8_t local;

  local = buf[0];

  printf("%x\n", local);

  buf[0]++;
}

int main(void)
{
    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};

    doSomething(myArray);

    return 0;
}

[Karl H. (kbuchegg)]

Michl schrieb:
> Naja ich will eigentlich kein anderes Array verwenden.
> myArray enthält den Datenstrom, den ich auswerten will.
>
> Immer häppchenweise. Beim ersten mal eben das 0x00 in meinem Beipsiel,
> danach 0x01, 0x02, usw.


ALso willst du sowas:

void doSomething(uint8_t **buf )
{
  uint8_t local;

  local = *buf[0];

  printf("%x\n", local);

  (*buf)++;
}

int main(void)
{
    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};
    uint8_t* nextElem;

    nextElem = myArray;

    doSomething( &nextElem );
    doSomething( &nextElem );

    return 0;
}

willkommen in der 2-Stern Programmierung, die sich völlig analog aus der 
Situation ableitet, wie eine Funktion vorgehen muss, damit sie eine 
Variable beim Aufrufer verändern kann

void foo( int * a )
{
  *a = 5;
}

int main()
{
  int c;

  foo( &c );
}

der Aufrufer übergibt einen Pointer auf die Variable und die Funktion 
kann über diesen Pointer die Variable des Aufrufers ändern. Das geht für 
alle Datentypen T

void foo( T * a )
{
  *a = für T zulässiger Wert;
}

int main()
{
  T c;

  foo( &c );
}

In deinem Fall ist T dann eben der Datentyp 'Pointer to uint8_t', weil 
du eine Variable brauchst, in der du fest hältst, wo in deinem Array das 
nächste zu bearbeitende Byte zu finden ist.

Also ersetzte T durch uint8_t und du erhältst

void foo( uint8_t * * a )
{
  *a = ....
}

int main()
{
  uint8_t * c;

  foo( &c );
}

dein c ist aber nicht irgendein c, sondern enthält eine Adresse, die in 
ein Array zeigt

void foo( uint8_t * * a )
{
  // a ist die Adresse von c
  // *a ist daher der INhalt von c. Der INhalt von c, das ist aber nichts
  //     anderes als die Adresse des nächsten zu verarbeitenden Zeichens
  // daher ist **a dieses Zeichen selber

  mach was mit **a

  // und vermerken, dass dieses Zeichen somit bearbeitet wurde. Das c
  // vom Aufrufer soll auf den nächsten Speicherplatz im Array zeigen
  (*a)++;
}

int main()
{
  uint8_t data[] = { 5, 4, 3, 2 };
  uint8_t * c = data;

  foo( &c );
}

[Rolf Magnus (Gast)]

Michl schrieb:
> sogar ohne Warnungen

Aha! Ich hatte mich schon gewundert, weil der Code davor eigentlich über 
die Typ-Unstimmigkeit hätte warnen müssen. Hat er also offenbar auch, 
aber du hast die Warnung für nicht wichtig genug befunden, um sie hier 
auch mit zu posten.

Michl schrieb:
> Der Umweg über
> help() ist ja letzendlich gleichwertig mit der von Rolf Magnus
> vorgeschlagenen Lösung, den lokalen Pointer anzulegen.

Ja, richtig. In dem Fall ist halt der Parameter buf der lokale Pointer.

Karl Heinz schrieb:
> Das hier
> void doSomething(uint8_t *buf[])
> besagt, dass buf ein Array von Pointer ist, wobei jeder Pointer auf
> (mindestens) einen uint8_t zeigt.

Nein. buf ist ein Zeiger auf einen Zeiger.

Karl Heinz schrieb:
> Aber wo sind diese Daten in deinem Programm.
> Wenn du sagst, du willst ein anderes Array benutzen (und das tust du mit
> deinem Code), dann muss es auch ein anderes Array geben. Wo ist dieses?

Er will nicht ein anderes Array benutzen, sondern mittels eines Pointers 
durch ein Array iterieren.

A. H. schrieb:
> Folglich ist
> uint8_t *buf[]
> nicht ein pointer auf ein Array, sondern ein Array von Pointern (auf
> uint8_t).

buf ist ein Funktionsparameter. Da haben die Klammern nichts mit Arrays 
zu tun. buf ist schlicht und ergreifend ein Zeiger auf einen Zeiger! 
uint8_t *buf[] ist als Parameter zu 100% äquivalent zu uint8_t ** buf.

[tictactoe (Gast)]

Karl Heinz schrieb:
> local = *buf[0];

Genau genommen

local = (*buf)[0];

was aber wegen der Null in den eckigen Klammern (und nur deswegen!) auf 
das gleiche raus läuft wie das, was du geschrieben hast.

[Bitflüsterer (Gast)]

Wozu man vielleicht noch ergänzend folgendes erwähnen kann.

Der Name eines Vektors ist nicht gleichbedeutend mit einer Variablen, 
die einen Zeiger enthält. Demzufolge kann man unter diesem Namen auch 
keinen Zeiger manipulieren.

Vielmehr ist der Name eines Vektors synonym zu einem Zeiger auf diesen 
Vektor. D.h. bei Verwendung des Vektornamens im Code wird an seiner 
Stelle, während der Compilation resp. Linken, ein Zeiger auf das erste 
Element verwendet. Hingegen existiert der Zeiger zur Laufzeit in keiner 
Weise als "Ding", das im Quellcode irgendwie nennbar wäre.

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

>> void doSomething(uint8_t *buf[])
>> besagt, dass buf ein Array von Pointer ist, wobei jeder Pointer auf
>> (mindestens) einen uint8_t zeigt.
>
> Nein. buf ist ein Zeiger auf einen Zeiger.

Wenn wir uns nur auf den Datentyp konzentrieren, dann schon.
Allerdings ist das hier in einer Situation, in der Arrays automatisch zu 
Zeigern decayen. Somit haben wir beide recht.

Letzten Endes geht es darum, dass in C die alternative Schreibweisen

void foo( T * arg )

und

void foo( T arg[] )

technisch gesehen aufs gleiche rauslaufen, auch wenn sie etwas anders 
suggerieren.

[Bitflüsterer (Gast)]

> willkommen in der 2-Stern Programmierung, ...

Grins.

[A. H. (ah8)]

Karl Heinz schrieb:
> A. H. schrieb:
>> Michl schrieb:
>>> Was ich herausgefunden habe:
>>> Nicht das Inkrementieren verursacht den Absturz, sondern die Zeile
>>> local = *buf[0];
>>> Aber wieso? Ich muss doch den Zeiger doppelt dereferenzieren, einmal
>>> durch den *-Operator, einmal durch [].
>>
>> Der []-Operator hat eine höhere Priorität, als der *-Operator. Folglich
>> ist
>
> Hier kommt eher die Rechts-Links Regel zur Anwendung
>
> http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

Naja, diese Regel würde ich eher als eine Gedankenstütze für 
Programmierer verstehen, denn der Compiler richtet sich bei der Analyse 
des Codes und dem Aufbau des Syntaxbaumes definitiv nach den 
Präzedenzregeln: Hat er den Identifikator erkannt (in diesem Fall buf) 
muss er entscheiden ob er den indizieren oder dereferenzieren soll. Da 
die Indizierung die höhere Präzedenz hat, wird er zunächst annehmen, 
dass es sich um ein Array handelt, dessen Element dann dereferenziert 
werden soll, also ein Pointer sein muss.

[Karl H. (kbuchegg)]

tictactoe schrieb:
> Karl Heinz schrieb:
>> local = *buf[0];
>
> Genau genommen
>

> local = (*buf)[0];
>

> was aber wegen der Null in den eckigen Klammern (und nur deswegen!) auf
> das gleiche raus läuft wie das, was du geschrieben hast.

Danke.
Den hab ich beim kopieren übersehen.

[Michl (Gast)]

Eins vorweg KH: dein Code funktioniert perfekt:

void doSomething(uint8_t **buf )
{
  uint8_t local;

  local = *buf[0];

  printf("%x\n", local);

  (*buf)++;
}

int main(void)
{
    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};
    uint8_t* nextElem;

    nextElem = myArray;

    doSomething( &nextElem );
    doSomething( &nextElem );

    return 0;
}

Aber: ändere ich die Zeile

local = *buf[0];

in doSomething() zu

local = *buf[1];

schmiert mein Programm wieder ab.

Langsam glaube ich dass hier mein eigentliches Problem liegt.

Worran kann das liegen?

[Rolf Magnus (Gast)]

tictactoe schrieb:
> Genau genommen
> local = (*buf)[0];

Da hier ja eh keine wirkliche Array-Indizierung benötigt wird, sondern 
einfach nur einen Zeiger auf einen Zeiger zweimal dereferenziert werden 
soll, würde ich gleich schreiben:

local = **buf;

Karl Heinz schrieb:
> Wenn wir uns nur auf den Datentyp konzentrieren, dann schon.
> Allerdings ist das hier in einer Situation, in der Arrays automatisch zu
> Zeigern decayen. Somit haben wir beide recht.

Naja, du meintest vorhin:

Karl Heinz schrieb:
> ist etwas völlig anderes und auch wenn du mittels eines Adressoperators
> erst mal alles ruhig gestellt hast, ändert das nichts an der Tatsache,
> dass deine Daten nicht den Aufbau haben, den die Funktion voraussetzt.

Die Daten haben aber durchaus den Aufbau, den die Funktion voraussetzt, 
auch wenn das auf den ersten Blick nicht so aussieht.

> Du kannst eine Kuh weiß anstreichen, aber das macht sie nicht zum
> Schimmel.

Tatsächlich ist es hier so, daß es bereits ein Schimmel ist, der nur 
durch die ulkige Syntax von C wie eine Kuh aussieht. ;-)

Karl Heinz schrieb:
> technisch gesehen aufs gleiche rauslaufen, auch wenn sie etwas anders
> suggerieren.

Ebenth!

[Bitflüsterer (Gast)]

>Worran kann das liegen?

Beitrag "Re: Zeiger auf Array?"

[Michl (Gast)]

Bitflüsterer schrieb:
> Beitrag "Re: Zeiger auf Array?"

Danke, im Eifer des Gefechts übersehen!

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:

> Die Daten haben aber durchaus den Aufbau, den die Funktion voraussetzt,
> auch wenn das auf den ersten Blick nicht so aussieht.

In seinem Originalbeispiel nicht.
Da fehlte die Zwischenebene einer Pointer-Variablen

@TO
>
> Aber: ändere ich die Zeile
> local = *buf[0];
> in doSomething() zu
>
> local = *buf[1];

Mittels

    uint8_t myArray[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05};
    uint8_t* nextElem;

    nextElem = myArray;

hast du jetzt das hier aufgebaut

   nextElem
   +-------+                   +------+
   |  o----------------------->| 0x00 |
   +-------+                   +------+
                               | 0x01 |
                               +------+
                               | 0x02 |
                                .....

Durch die Übergabe an die Funktion hast du eine weitere Ebene eingebaut

   buff
  +-------+
  |  o-----------+
  +-------+      |
                 |
                 v
              +--------+             +------+
     nextElem |  o------------------>| 0x00 |
              +--------+             +------+
                                     | 0x01 |
                                     +------+
                                     | 0x02 |
                                       ....

was besagt nun

    *buf[0]

es besagt: verfolge den Zeiger buf und dort wo er hin führt, nimm das 
Array Element 0 (das ist jetzt etwas salopp formuliert, aber darauf 
läuft es hinaus).
Nun, wo zeigt denn buf hin?
buf zeigt auf nextElemen (auch wenn buf davon nichts weiß). nextElem ist 
kein Array, aber durch den Array-Pointer Dualismus ist das bei [0] ok. 
Da passiert nichts.

Ganz anders aber bei

    *buf[1]

jetzt willst du durch das [1] hier

   buff
  +-------+
  |  o-----------+
  +-------+      |
                 |
                 v
              +--------+             +------+
     nextElem |  o------------------>| 0x00 |
              +--------+             +------+
                ######               | 0x01 |
                                     +------+
                                     | 0x02 |
                                       ....

zugreifen und dir von hier den Pointer holen, mit dem du dann auf die 
eigentlichen Daten weiter zugreifst (was dann der * in *buf[1] gemacht 
hätte).
Nur sieht man in der Grafik auch: An der Stelle der ####### ist gar kein 
Zeiger! Du greifst auf irgendeinen Speicher zu, und was immer auch dort 
im Speicher steht, es wird als die Adresse aufgefasst, mit der dann 
weiter dereferenziert wird.

Und das geht dann in die Hose.

Und ich schliesse mich Rolf an.
Da das, worauf buf zeigt, in erster Linie gar kein Array ist, würde ich 
das auch nicht mit Array Syntax schreiben, sondern als

   **buf

schreiben. Die Array Indizierung, die zwar bei [0] das identische 
Verhalten hervorruft, führt einen hier in die Irre: sie gaukelt etwas 
vor, was nicht da ist: Das worauf buf zeigt ist kein Array (auch wenn es 
eines sein könnte und sich an der Syntax dadurch nichts ändern würde)

[A. H. (ah8)]

Rolf Magnus schrieb:
> A. H. schrieb:
>> Folglich ist
>> uint8_t *buf[]
>> nicht ein pointer auf ein Array, sondern ein Array von Pointern (auf
>> uint8_t).
>
> buf ist ein Funktionsparameter. Da haben die Klammern nichts mit Arrays
> zu tun. buf ist schlicht und ergreifend ein Zeiger auf einen Zeiger!
> uint8_t *buf[] ist als Parameter zu 100% äquivalent zu uint8_t ** buf.

Einigen wir uns auf die Formulierung: Der Compiler wandelt implizit eine 
Array von Pointern in ein Pointer auf Pointer? Syntaktisch bleibt der 
Ausdruck nämlich ein  Array von Pointern, ungeachtet der semantischen 
Kapriolen, die der Compiler dann damit treibt (und die sicherlich zum 
weniger glücklichen historischen Erbe von C gehören). Technisch gesehen 
ist Deine Aussage natürlich richtig, was den Lerneffekt betrifft hielte 
ich in diesem Fall die Unterscheidung zwischen Pointer auf Array und 
Array von Pointern aber für wichtiger, die spätestens dann relevant 
wird, wenn die Indexklammern nicht mehr leer (bzw. != 0) sind und die 
offenbar nicht ganz einfach ist, wie der immer noch fehlerhafte 
Quelltext und die wiederholten Fragen des TO deutlich zeigen. Man möge 
mir die kleine technische Ungenauigkeit an dieser Stelle daher verzeihen 
:-)

[Rolf Magnus (Gast)]

A. H. schrieb:
> Syntaktisch bleibt der Ausdruck nämlich ein  Array von Pointern,
> ungeachtet der semantischen Kapriolen, die der Compiler dann damit treibt
> (und die sicherlich zum weniger glücklichen historischen Erbe von C
> gehören).

Es ist eines der Dinge in C, die ursprünglich die Sprache intuitiver 
hätten machen sollen, aber leider (zumindest für jemanden, der die 
Sprache wirklich verstehen will) genau das Gegenteil tun. Gut - kann man 
heute nicht mehr ändern.
Um es nochmal auf die schöne Analogie von Karl-Heinz zu beziehen: Ich 
will eine Kuh und bekomme stattdessen einen Schimmel, der so angemalt 
ist, daß er aussieht wie eine Kuh. Spätestens beim melken fällt einem 
dann auf, daß da was nicht stimmt.

A. H. schrieb:
> Man möge mir die kleine technische Ungenauigkeit an dieser Stelle daher
> verzeihen :-)

Das ist vielleicht ein anderer pädagogischer Ansatz. Ich erkläre lieber 
einem Einsteiger die Dinge korrekt, auch wenn's das am Anfang 
komplizierter macht. Es mag aber auch Vorteile haben, manchmal nicht so 
genau auf die Details zu achten, um den Einstieg zu erleichtern.