Pourquoi certaines fonctions déclarées extern et le fichier d'en-tête non inclus dans la source dans le code source de Git?

strbuf.c comprend cache.h et cache.h comprend strbuf.h, de sorte que votre prémisse de la question 2 (qui strbuf.c ne comprend pas strbuf.h) est faux: il ne l'inclure, mais pas directement.

extern appliqué à des fonctions

La extern mot-clé n'est jamais nécessaire pour les déclarations de fonction, mais il a un effet: il déclare que l'identificateur de nommage de la fonction (c'est à dire, le nom de la fonction) a le même lien que précédemment visible déclaration, ou si aucune déclaration n'est visible que de l'identifiant liaison externe. Cela prête à confusion, le phrasé vraiment signifie que, compte tenu:

static int foo(void); extern int foo(void);

la deuxième déclaration de foo déclare, en outre, il static, en lui donnant une liaison interne. Si vous écrivez:

static int foo(void); int foo(void); /* wrong in 1990s era C */

vous avez déclaré, car avoir une liaison interne, et ensuite la deuxième comme ayant une liaison externe, et en pré-1999 versions de C,¹ qui produit un comportement indéfini. Dans un sens, puis, le extern mot-clé ajoute un peu de la sécurité (au prix de la confusion), car il peut signifier static lorsque cela est nécessaire. Mais vous pouvez toujours écrire static de nouveau, et extern n'est pas une panacée:

extern int foo(void); static int foo(void); /* ERROR */

Cette troisième forme est toujours erronée. La première extern déclaration n'a pas de précédent visible déclaration, de sorte foo a une liaison externe, puis la deuxième static déclaration donne foo liaison interne, produisant un comportement indéfini.

En bref, extern n'est pas nécessaire sur les déclarations de fonction. Certaines personnes préfèrent pour style raisons.

(Note: je suis en laissant extern inline en C99, qui est une sorte de bizarre, et les implémentations varient. Voir http://www.greenend.org.uk/rjk/2003/03/inline.html pour plus de détails.)

extern appliquée à des déclarations de variable

La extern mot-clé sur une déclaration de variable a de multiples effets différents. Tout d'abord, comme avec les déclarations de fonction, il affecte le lien de l'identificateur. Deuxièmement, pour un identificateur à l'extérieur de toute fonction (une "variable globale" dans l'un des deux sens habituel), il provoque la déclaration une déclaration, plutôt qu'une définition, à condition que la variable n'est pas initialisée.

Pour les variables à l'intérieur d'une fonction (c'est à dire, avec "bloc de portée"), comme somevar:

void f(void) {
    extern int somevar;
    ...
}

la extern mot-clé provoque l'identificateur d'avoir quelques liens (internes ou externes) au lieu de "pas de lien" (automatique-durée variables locales). Dans le processus, il provoque également la variable elle-même pour avoir la durée statique, plutôt qu'automatique. (Automatique-durée variables n'ont jamais de liaison, et d'avoir toujours le bloc de portée, plutôt que de la portée du fichier.)

Comme avec les déclarations de fonction, le lien extern ayants droit interne si il y a un précédent visible interne-lien de la déclaration et de l'extérieur du contraire. Ainsi, le x à l'intérieur de f() ici a une liaison interne, en dépit de la extern mot-clé:

static int x;
void f(void) {
    extern int x; /* note: don't do this */
    ...
}

La seule raison d'écrire ce genre de code est de confondre les autres programmeurs, afin de ne pas le faire. 🙂

En général, la raison pour annoter "global" (c'est à dire, fichier-champ d'application, la statique de la durée, externe-lien) variables avec la extern mot-clé est d'éviter qu'particulièrement la déclaration de devenir une définition. Les compilateurs C qui utilisent le soi-disant "def/ref du modèle" avoir une indigestion au moment de la liaison lorsque le même nom est défini plusieurs fois. Ainsi, si file1.c dit int globalvar; et file2.c dit aussi int globalvar;, les deux définitions sont données et le code ne se compile pas (bien que la plupart des systèmes de type Unix utiliser la soi-disant "modèle commun" par défaut, ce qui rend ce travail de toute façon). Si vous déclarez une telle variable dans un fichier d'en-tête—qui est susceptible d'être compris de différentes .c fichiers—utiliser extern de faire cette déclaration "déclaration".

Une, et une seule, de ces .c fichiers peuvent ensuite déclarer la variable de nouveau, laissant le extern mot-clé et/ou comprenant un initialiseur. Ou, certaines personnes préfèrent un style dans lequel le fichier d'en-tête utilise quelque chose comme ceci:

/* foo.h */
#ifndef EXTERN
# define EXTERN extern
#endif
EXTERN int globalvar;

Dans ce cas, l'une (et une seule) de ces .c fichiers peuvent contenir la séquence:

#define EXTERN
#include "foo.h"

Ici, depuis EXTERN est défini, le #ifndef désactive le subséquentes #define et la ligne EXTERN int globalvar; étend à juste int globalvar; de sorte que cela devient une définition plutôt que d'une déclaration. Personnellement, je n'aime pas ce style de codage, bien qu'il ne satisfaire le "don't repeat yourself" principe. La plupart du temps je trouver les majuscules EXTERN trompeuse, et cette tendance est inutile avec l'initialisation. Ceux qui la favorisent généralement la liquidation de l'ajout d'une deuxième macro pour masquer les initialiseurs:

#ifndef EXTERN
# define EXTERN extern
# define INIT_VAL(x) /*nothing*/
#else
# define INIT_VAL(x) = x
#endif

EXTERN int globalvar INIT_VAL(42);

mais même cela tombe à l'eau lorsque le point d'être initialisé besoin d'un composé de l'initialiseur (par exemple, un struct qui doit être initialisée à { 42, 23, 17, "hike!" }).

(Note: j'ai délibérément écarté toute "tentative de définition de la" chose ici. Une définition sans un initialiseur n'est "provisoirement défini" jusqu'à la fin de l'unité de traduction. Cela permet à certains types de références qui sont trop difficiles à exprimer. C'est normalement pas très important).

y compris l'en-tête qui déclare la fonction f dans le code qui définit la fonction f

C'est toujours une bonne idée, pour une raison simple: le compilateur va comparer les déclaration de f() dans l'en-tête contre les définition de f() dans le code. Si les deux ne correspondent pas (pour une raison quelconque—généralement une erreur dans le codage initial, ou l'échec de la mise à jour de l'un des deux au cours de l'entretien, mais de temps en temps, simplement à cause de Chat marcher Sur le Clavier Syndrome ou similaire), le compilateur peut intercepter l'erreur au moment de la compilation.

---

¹1999 C standard dit que l'omission de la extern mot-clé dans une déclaration de fonction, signifie la même chose qu'à l'aide de la extern mot-clé. C'est beaucoup plus simple à décrire, et qui signifie que vous avez défini (et raisonnable) comportement au lieu de l'indéfini (et donc peut-être bien peut-être-un mauvais comportement).

OriginalL'auteur torek