Il n'y a pas de magie. Quand un programme C est compilé, il y a deux étapes majeures.D'abord, chaque unité de compilation individuelle est compilée dans son isolation. (Une unité de compilation est essentiellement un fichier .c, plus tout ce qu'il contient). À ce stade, il ne sait rien de ce qui est contenu dans les autres fichiers .c, ce qui signifie qu'il ne peut pas générer un programme complet. Qu'est-ce qu'il peut faire est de générer du code avec quelques "remplir les blancs" des taches. Si, depuis foo.c, vous appelez une fonction déclarée dans bar.h et définie dans bar.c, alors le compilateur peut seulement voir que la fonction existe. Il est déclaré dans bar.h, donc nous devons supposer que la définition complète existe quelque part. Mais parce que cette définition est à l'intérieur d'une autre unité de compilation, nous ne pouvons pas encore la voir. Ainsi, le compilateur génère du code pour appeler la fonction, avec une petite note disant "remplir l'adresse de cette fonction une fois qu'elle est connue".
Une fois que chaque unité de compilation a été compilée de cette manière, il vous reste un tas de fichiers objets (typiquement .o si compilés par GCC, et .obj si vous utilisez MSVC), contenant ce genre de "remplir le code "blanc".
Maintenant, l'éditeur de liens prend tous ces fichiers objet, et essaie de les fusionner ensemble, ce qui lui permet de remplir les blancs. La fonction pour laquelle nous avons généré un appel ci-dessus peut maintenant être trouvée, ainsi nous pouvons insérer son adresse dans l'appel.
Ainsi, rien de spécial ne se produit si un fichier .c a le même nom qu'un fichier .h. C'est juste une convention pour aider les humains à comprendre ce qu'il y a dans chaque fichier.
Le compilateur s'en fout. Il prend juste chaque fichier .c, plus tout ce qu'il contient, et le compile dans un fichier objet. Et puis l'éditeur de liens fusionne tous ces fichiers objet en un seul exécutable.