Différence entre [] et *

Bonjour à tous et tout d'abord bonne et heureuse année 2017.

Je suis confronté à un petit problème de compréhension.

J'ai acheté le livre 'Le guide complet du langage C' aux éditions Eyrolles et dans ce livre il est écrit au chapitre 6.1 page 290 ceci :

On peut déclarer un prototype de fonctions comme suit et ils seront équivalents avec des tableaux en arguments muets:

Code:

---

1 2 3 4 5 6

void function( int * t );   void function( int t[10] );   void function( int t[] );

---

et cela fonctionne très bien en C sous Visual Studio, ou Keil.

Maintenant si je considère qu'une structure peut avoir une représentation sous la forme d'un tableau, je peux éventuellement écrire ce qui suit:

Code:

---

1 2 3 4 5 6 7 8

/** Déclaration anticipée **/ struct enreg; typedef struct enreg Ts_enreg;   /** Prototypes **/ void function_ptr( Ts_enreg * objects); //---> compilateur dit OK ! void function_array( Ts_enreg objects[]); //---> compilateur dit KO car enreg n'est pas encore défini !!

---

On dirait que le compilo (qui n'est pas visual) fait la distinction entre * et [].
J'ai contacté le support technique et la réponse est la suivante :

Citation:

---

Si votre manuel prétend que cela est censé fonctionner, vous avez besoin d'un autre, parce que celui que vous avez n'est pas réellement sur le langage de programmation C.

"Les prototypes MyFunc_1 et MyFunc_2 sont équivalents"

Non, ils ne sont pas. C'est une chose de déclarer une fonction qui prend un type inconnu, mais tout à fait différent si elle prend un pointeur vers ce type inconnu.

---

Qu'en pensez-vous ?

Bonjour,
de ce que tu montres, struct enreg n'est pas «inconnu», puisque justement tu le déclares, mais incomplet car tu ne le définis pas. Cela signifie principalement que tu ne pourras pas l'utiliser directement pour déclarer une variable car la taille de ce type est a priori inconnu. En revanche tu pourras toujours utiliser un pointeur sur ce type car la taille d'un pointeur est elle connue.

Maintenant ce que je peux rajouter est simplement ce que la norme C11 dit à la section 6.7.6.3 Function declarators, paragraphe 12

Citation:

---

If the function declarator is not part of a definition of that function, parameters may have incomplete type and may use the[*] notation in their sequences of declarator specifiers to specify variable length array types.

---

Cela signifie que tu peux déclarer une fonction dont les paramètres utilisent des types incomplets.

Un peu avant au paragraphe 7 on peut lire :

Citation:

---

A declaration of a parameter as ‘‘array of type’’ shall be adjusted to ‘‘qualified pointer to type’’, where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. [...]

---

Donc oui les déclarations sont équivalentes dans le sens où si le compilateur voit la déclaration void function_array( Ts_enreg objects[]); alors il la transforme en void function_array( Ts_enreg *objects);.

Donc un compilateur conforme ne devrait pas râler, du moins tant que tu n'essayes pas de fournir une définition de la fonction avant de donner la définition de ton type incomplet.

PS: Il va y avoir une toute petite différence quand tu utilises static avec une taille. Bien que les déclarations suivantes soient compatibles pour tout type T (sauf void) :

Code:

---

1 2 3 4 5 6

void foo(size_t n, T *array); void foo(size_t n, T array[]); void foo(size_t n, T array[n]); void foo(size_t n, T array[*]); void foo(size_t n, T array[10]); void foo(size_t n, T array[static 10]);

---

la dernière est un peu particulière car tu t'engages à fournir un paramètre array qui sera un pointeur vers au moins 10 objets de type T consécutifs en mémoire. Le compilateur pourra alors faire des hypothèses d'optimisations (comme le paramètre array ne sera pas NULL, …) qui pourraient donner des comportements aberrants si tu ne respectes pas ton engagement.

@picodev : merci de ta réponse complète avec citation des sources ! j'adore !

J'ai le même problème avec GCC 6.3.0.

Bout de code testé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <stdio.h>   struct enreg; typedef struct enreg Ts_enreg; void function_ptr (Ts_enreg * objects ); void function_array(Ts_enreg objects[]); // error: array type has incomplete element type 'Ts_enreg {aka struct enreg}'   struct enreg {}; void function_ptr (Ts_enreg * objects ) {} void function_array(Ts_enreg objects[]) {}   int main() { #ifdef __GNUC__ printf("GCC version: %s\n\n", __VERSION__); #endif return 0; }

---

Soit c'est un bogue de GCC, soit il y a une subtilité qui m'échappe.

D'ailleurs, toujours avec GCC 6.3.0, le même code compile très bien en C++.

Comme quoi il faut toujours bien chercher avant de répondre ^^

D'après ce que je comprends, la norme impose que pour toute déclaration de tableau le type des objets ne soit pas incomplet au paragraphe 1 de la section 6.7.6.2 Array declarators :

Citation:

---

[...] The element type shall not be an incomplete or function type. [...]

---

Et cela vaut donc apparemment aussi pour la déclaration d'un paramètre de type tableau de.

J'ai trouvé une petite explication de pourquoi du comment dans un defect report du comité de normalisation de C qui date de 1992 (Defect Report #407) :

Citation:

---

Are the following declarations strictly conforming?
/* 1 */ struct S;
/* 2 */ struct S *f(struct S *p) {return p; }
/* 3 */ struct S *g(struct S a[]) {return a; }

[...]
The function g is more interesting. A parameter of type array is adjusted to pointer type (subclause 6.7.1, page 82, lines 23-26). (Note that is an adjustment of the type of the parameter definition. It is not a conversion, as is what happens when an argument of type array is passed to a function.) Thus, the type of parameter a is pointer to struct S. This would seem to make the function g the same case as function f. However, subclause 6.1.2.5, page 23, lines 23-24 (also Footnote 17) disallow array types from having an incomplete element type (like struct S). This raises the question, is function g strictly conforming because the type of a is really pointer, or is function g not strictly conforming because a had an invalid array type before the compiler in effect rewrote the declaration?
[...]
Response
First of all, no constraints are violated. Therefore, no diagnostics are required.
Declarations 1, 2, and 5 are strictly conforming. Declarations 3, 4, and 6 are not, and therefore cause undefined behavior.
The struct S is an incomplete type (subclause 6.5.2.3, page 62, lines 25-28). Also, an array of unknown size is an incomplete type (subclause 6.5.4.2, page 67, lines 9-10). Therefore, arrays of either of the above are not strictly conforming (subclause 6.1.2.5, page 23, lines 23-24). This makes declarations 3, 4, and 6 not strictly conforming. (But an implementation could get it right.)
As an aside, array parameters are adjusted to pointer type (subclause 6.7.1, page 82, lines 23-24). However, there is nothing to suggest that a not-strictly-conforming array type can magically be transformed into a strictly conforming pointer parameter via this rule.
The types in question can be interpreted two different ways. (Array to pointer conversion can happen as soon as possible or as late as possible.) Hence a program that uses such a form has undefined behavior.

---

Même si là ça concerne plus une définition qu'une déclaration.

Désolé pour la mauvaise piste !

Merci pour le temps passé !

Vous avez entièrement répondu à mes interrogations !