pointer auf typedef array

[Holger K. (holgerkraehe)]

Hallo zusammen

Ich versuche meiner Funktion ein struct array zu übergeben.

Leider mache ich wohl irgendwas falsch:

typedef struct {
  jsmntype_t type;
  int start;
  int end;
  int size;
} jsmntok_t;

...

meineFunktion(jsmntok_t *tokens[])
{
  tokens[0]->....;
}


....

jsmntok_t tokens[1024];

meineFunktion(&tokens[0]);

Leider bekomme ich immer die Meldung:

expected 'jsmntok_t ** {aka struct <anonymous> **}' but argument is of type 'jsmntok_t (*)[1024] {aka struct <anonymous> (*)[1024]}'

..\foo.c:137:64: warning: passing argument 1 of 'meineFunktion' from incompatible pointer type [-Wincompatible-pointer-types]

Weiss jemand Rat?
Danke!

[Johann L. (gjlayde)]

Holger K. schrieb:

meineFunktion(jsmntok_t *tokens)

oder

meineFunktion(jsmntok_t tokens[])

[Johann L. (gjlayde)]

Holger K. schrieb:

...und der Zugriff dann:

tokens[0].....;

zähl deine Punkte :-P

[Holger K. (holgerkraehe)]

Johann L. schrieb:
> meineFunktion(jsmntok_t *tokens)

Dann kommt:

invalid type argument of '->' (have 'jsmntok_t {aka struct <anonymous>}')

Bei

tokens[0]->....;

Johann L. schrieb:
> meineFunktion(jsmntok_t tokens[])

Würde wohl funktioniere, aber hier würde ja der Inhalt kopiert werden.
Dies möchte ich ja eben nicht.

[Rufus Τ. F. (rufus)]

Holger K. schrieb:
> Johann L. schrieb:
>> meineFunktion(jsmntok_t tokens[])
>
> Würde wohl funktioniere, aber hier würde ja der Inhalt kopiert werden.
> Dies möchte ich ja eben nicht.

Das wird er auch nicht. tokens[] ist an dieser Stelle absolut identisch 
zu *tokens.

[Nop (Gast)]

Holger K. schrieb:
> meineFunktion(&tokens[0]);

Die mußt Du dann natürlich auch so aufrufen:
meineFunktion(tokens);

[Johann L. (gjlayde)]

Nop schrieb:
> Die mußt Du dann natürlich auch so aufrufen:
> meineFunktion(tokens);

Muss nicht aber kann.

[Nop (Gast)]

Johann L. schrieb:

> Muss nicht aber kann.

Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist, 
aber nicht der assoziierte Typ.

[Carl D. (jcw2)]

Nop schrieb:
> Johann L. schrieb:
>
>> Muss nicht aber kann.
>
> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,
> aber nicht der assoziierte Typ.

Das macht in reinem C keinen Unterschied.
Außer natürlich für den Code-Leser.

[Nop (Gast)]

Carl D. schrieb:

> Das macht in reinem C keinen Unterschied.

Wenn wie hier, bei der Übergabe an eine Funktion nicht, weil C dann eh 
castet. Beim Benutzen von sizeof schon.

> Außer natürlich für den Code-Leser.

Und damit auch für Code-Analysetools, die einen vor Typfehlern warnen 
sollen. Mich würd's nicht wundern, wenn je nach Warnstufe sogar der eine 
oder andere Compiler meckern würde.

[Carl D. (jcw2)]

Nop schrieb:
> Carl D. schrieb:
>
>> Das macht in reinem C keinen Unterschied.
>
> Wenn wie hier, bei der Übergabe an eine Funktion nicht, weil C dann eh
> castet. Beim Benutzen von sizeof schon.

Deshalb hat der Holger auch einen eigenen Thread zum Thema sizeof.
Weil's darum hier nicht geht.

[Johann L. (gjlayde)]

Nop schrieb:
> Johann L. schrieb:
>
>> Muss nicht aber kann.
>
> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,
> aber nicht der assoziierte Typ.

Wenn ich mit gcc folgendes übersetze

typedef struct { char a[3]; } __attribute((packed)) S;

S g[7];

#define T(x,y) _Generic((x), __typeof(y):1, default:0)

int main()
{
    static char volatile v;
    v = T (g, g);
    v = T (g, &g[0]);
    __typeof(g) b;
    v = sizeof (g);
    v = sizeof (b);
}

dann werden nacheinander folgende Werte in v gespeichert: 0, 1, 21, 21.

Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g 
sondern den von &g[0]?

Verwirrt ich bin.  Oder ist das ein Bug?

[Carl D. (jcw2)]

Johann L. schrieb:
> Nop schrieb:
>> Johann L. schrieb:
>>
>>> Muss nicht aber kann.
.
>> Sollte, weil zwar die übergebene Adresse in beiden Fällen dieselbe ist,
>> aber nicht der assoziierte Typ.
.
> Wenn ich mit gcc folgendes übersetzetypedef struct { char a[3]; }
> __attribute((packed)) S;
>
> S g[7];
>
> #define T(x,y) _Generic((x), __typeof(y):1, default:0)
>
> int main()
> {
>     static char volatile v;
>     v = T (g, g);
>     v = T (g, &g[0]);
>     __typeof(g) b;
>     v = sizeof (g);
>     v = sizeof (b);
> }
> dann werden nacheinander folgende Werte in v gespeichert: 0, 1, 21, 21.
>
> Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g
> sondern den von &g[0]?
>
> Verwirrt ich bin.  Oder ist das ein Bug?

Wenn (x) als Parameter der "Funktion" _Generic() angesehen wird, 
__typeof() aber den "echten" Typ ermittelt, dann würde es passen.
Wenn auch etwas strange.

[Rolf M. (rmagnus)]

Nop schrieb:
> Mich würd's nicht wundern, wenn je nach Warnstufe sogar der eine
> oder andere Compiler meckern würde.

Ich hoffe nicht, denn der implizite "Zerfall" von Arrays in einen Zeiger 
auf deren erstes Element ist ein ziemlich grundlegendes Konzept in C, 
das fast überall vorkommt, wo Arrays eingesetzt werden.

Johann L. schrieb:
> Die beiden letzten Werte sind klar, aber warum hat g nicht den Typ von g
> sondern den von &g[0]?

Weil auf das erste g der Array-zu-Zeiger-Zerfall auch angewendet wird, 
auf das zweite aber nicht.
Aus http://en.cppreference.com/w/c/language/generic :

The conversion is performed in type domain only: it discards the 
top-level cvr-qualifiers and atomicity or applies array to 
pointer/function-to-pointer transformations to the type of the 
controlling expression, without initiating any side-effects or 
calculating any values.
Therefore, "abc" matches char* and not char[4] and (int const){0} 
matches int, and not const int.

[Nop (Gast)]

Rolf M. schrieb:

> Ich hoffe nicht, denn der implizite "Zerfall" von Arrays in einen Zeiger

Hast natürlich recht, weil &array[0] dann auch genau den richtigen 
Zeigertyp hat für die Funktion.