topologie : les fonctions , au-delà du header ?

Bonjour à tous !

Je viens vers vous pour chercher un peu d'aide et voir plus clair dans mon système.
Venant de la logique câblée ( robotique industrielle ) je me pose beaucoup de questions sur les "sources" des outils que j'utilise , et cette déformation professionnelle appliquée au C ( que je ne pratique pas vraiment encore , je débute - par curiosité envers Linux ) m'amène probablement un peu trop loin pour google dont je ne sais pas vraiment me servir non plus on dirait :)

Je me suis procuré " Le langage C " de Kernighan&Ritchie , je fais les exercices etc etc... Arrive le moment où je veux comprendre le système de Header. J'ouvre stdio.h et me mets à chercher le prototype de fclose() , sans autre raison que la compréhension du système. Je trouve :

extern int fclose (FILE *_stream);

j'identifie extern comme une classe de stockage , ce qui déjà devrait m'occuper un certain temps !

Puis j'essaye de trouver la fonction en .c sur ma machine ( linux 4.19.0-16 ), mais rien. Les moteurs de recherche m'orientent toujours sur l'utilisation des fonctions , mais pas vers le code source.

Et voici donc ma question : un programme C utilise include , qui envoie vers un .h qui contient des prototypes. Mais où est le code de la fonction ?

Merci d'avance !

Citation:

---

Envoyé par dhuasca

Mais où est le code de la fonction ?

---

Dans les fichiers source .c :weird:

Sinon tu peux directement fournir le code compilé dans 1 bibliothèque si tu ne veux pas divulguer ton code : .lib/ .dll/ .a/ .so

Et enfin, dans les entêtes .h (les macros essentiellement) mais il faut bien positionner les include guards (<- lien wiki en français)

Et accessoirement :whistle:, 1 fonction est toujours externe, donc la mettre en extern ne sert à rien.

Bonjour,

Le fichier d'entête n'est là que pour que le compilateur ait toutes les caractéristiques d'accès à la fonction. Quand un code est compilé, tout ce qui est accédé doit avoir une interface connue, c'est le pourquoi des #include.

La fonction est quelque part dans un code C, mais des fonctions sont parfois dans un code en assembleur ou des appels système.
Ce code C a été préalablement compilé (peut-être par toi pendant la procédure d'installation de la chaine de compilation.) Je pense qu'il est sur ta machine, mais comment s'appelle le fichier C qui contient la fonction fclose()? Ça tu ne le sais pas, moi non plus. Donc il faut chercher dans tous les fichiers C!
Le résultat a alors été mis dans un fichier dit de bibliothèque (un .a .lib .so le nom et le suffixe dépendent du système.) Comme c'est la bibliothèque standard on n'a pas besoin d'indiquer son nom lors de l'édition des liens (cf plus bas.)

Quand toi tu "compiles", il se passe 2 choses:
- la compilation de tes fichiers à toi
- l'édition des liens. Qui va relier tous tes fichiers compilés mais aussi toutes les bibliothèques que tu utilises pour en extraire les fonctions réellement utilisées.
ça donne un fichier exécutable.

Le mot extern dans l'extrait que tu donnes en fait ne sert à rien devant une fonction! Il pourrait être absent.

Et attention de ne pas apprendre un C trop ancien. Denis Ricchie est mort depuis quelques années et Kernighan n'est plus tout jeune. Le C bouge peu, mais en 40 ans il peut se passer des choses.

Bonjour,

Pour des bibliothèques libres, on peut trouver le code source qui est généralement imbitable. Par exemple pour la gnu libc il y a un dépot git sur sourceware. Mais il y en a d'autres comme musl.

C est un peu particulier en ce sens que le standard décrit à la fois le langage (utilisé par les équipes de dèv de compilo) et une bibliothèque standard (utilisé par les équipes de dèv de libc). Ces deux équipes ne sont en général pas les mêmes.

Si tu es curieux, tu peux également consulter la préhistoire d'unix et de C sur the unix heritage society. Ces sources ne sont plus utilisées … ce n'est que pour informations «comment on codait avant».

Bonjour,

Citation:

---

Envoyé par dhuasca

Je me suis procuré " Le langage C " de Kernighan&Ritchie , je fais les exercices etc etc... Arrive le moment où je veux comprendre le système de Header. J'ouvre stdio.h et me mets à chercher le prototype de fclose() , sans autre raison que la compréhension du système. Je trouve :

extern int fclose (FILE *_stream);
j'identifie extern comme une classe de stockage , ce qui déjà devrait m'occuper un certain temps !
......
Et voici donc ma question : un programme C utilise include , qui envoie vers un .h qui contient des prototypes. Mais où est le code de la fonction ?

Merci d'avance !

---

En réalité, la fonction "fclose" est une directive(#define fclose(fp) _IO_new_fclose (fp)) dont la véritable déclaration de la fonction est "extern int _IO_new_fclose;" (dans stdio.h) et le corps de la déclaration (le code source de la fonction) se trouve dans tout ce qui est lié aux entrées sorties plus précisément dans le fichier "glibc/libio/iofclose.c".

En complément : à chaque fois que vous définissez, une fonction en langage de programmation C de la sorte "exemple int foo();", le mot-clé externe est systématiquement mis par votre compilateur au début de la définition de la fonction de manière implicite cela permet d’étendre la visibilité de la fonction à l’ensemble de votre programme, et ainsi, les fonctions peuvent être utilisées n’importe où dans n’importe lequel des fichiers de l’ensemble du programme, mais sous réserve que la déclaration de la fonction soit connue. Ainsi donc et comme mentionnée plus haut "int foo();" = "extern int foo();"

à bientôt.

Merci beaucoup pour vos reponses , elles sont tres eclairantes ! J'avais completement omis le compilateur !
Du coup je cherchais un lien dans <stdio.h> qui m'amenerait vers le .c de la fonction. Mais si je comprends bien, le compilateur connait tout les chemins de la bibliotheque standard ?

Je devrais chercher un index de la norme , si par exemple je voulais consulter le code d'une fonction de cette bibliotheque ?
Ou bien existe-t-il une commande dans le compilateur qui permet de recuperer le chemin vers la fonction ?

Citation:

---

Envoyé par dhuasca

Du coup je cherchais un lien dans <stdio.h> qui m'amenerait vers le .c de la fonction. Mais si je comprends bien, le compilateur connait tout les chemins de la bibliotheque standard ?

---

Le compilateur ne connait rien :mrgreen: il est là pour vérifier si tout est bon : les types, le nombre de paramètres, la syntaxe, …, et génère tout ce qu'il peut en code intermédiaire (<- mais je peux me tromper)
C'est l'éditeur de liens qui va créer le résultat (exécutable, …) en prenant le travail du compilateur et en complétant avec les bibliothèques.

Edit: tiens, il me semble :koi: qu'il y a 1 différence entre #include "stdio.h" (recherche locale) et #include <stdio.h> (recherche dans les chemins connus)

Citation:

---

Envoyé par dhuasca

Je devrais chercher un index de la norme , si par exemple je voulais consulter le code d'une fonction de cette bibliotheque ?

---

pour la librairie standard, le code doit se trouver sur github ou 1 site bien spécifique :koi: il faudrait chercher

Edit: @WhiteCrow a donné 1 lien :zoubi:

Citation:

---

Envoyé par dhuasca

Ou bien existe-t-il une commande dans le compilateur qui permet de recuperer le chemin vers la fonction ?

---

C'est le rôle de l'IDE (EDI en français) de faire les sauts de l'utilisation/ déclaration à la définition.

Mais si le code est dans 1 bibliothèque, tu ne peux rien faire à part désassembler :zoubi:
Comme je l'ai dit, c'est pour ne pas divulguer le code.

La libc (bibliothèque standard de C) est tellement centrale et essentielle dans les systèmes unix que le compilateur la lie automatiquement à moins que l'utilisateur ne dise le contraire. Pour les autres bibliothèques il faut spécifier explicitement la demande de lien.

Pour savoir quelle bibliothèque C standard est utilisée par l'OS, il y a la commande ldd :

Code:

---

1 2 3 4 5

$ ldd /bin/ls linux-vdso.so.1 (0x00007ffd22d9d000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fdf26dd3000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fdf26c07000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fdf26e22000)

---

À moins d'avoir une configuration spéciale ce sera très probablement celle utilisée par ton éditeur de lien.

Pour avoir la liste des répertoires cherchés par défaut tu peux essayer un

Code:

---

1 2 3 4 5

$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012 SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")

---

Bonjour

Citation:

---

Envoyé par dhuasca

Et voici donc ma question : un programme C utilise include , qui envoie vers un .h qui contient des prototypes. Mais où est le code de la fonction ?

---

C'est un peu pareil pour fopen() ou printf() ou strcpy() ou malloc() et pour toutes les autres fonctions de la librairie standard d'où la réponse qui coule de source: "dans la librairie standard".
Un exécutable est composé d'un (ou de plusieurs) sources + de codes objets déjà compilés et stockés dans ce qu'on appelle des "librairies" (une gros "melting polt" qui contient tous les codes objets associés à toutes les fonctions dites "de base").
Cette librairie est automatiquement liée à ton code lors de la compilation. C'est aussi pour ça que si tu crées des fonctions et que tu les nommes fopen() ou printf() ou strcpy() ou malloc() là tu auras des soucis car le compilo ne saura pas, lors de l'édition des liens, laquelle il doit lier.

Citation:

---

Envoyé par dhuasca

Je devrais chercher un index de la norme , si par exemple je voulais consulter le code d'une fonction de cette bibliotheque ?
Ou bien existe-t-il une commande dans le compilateur qui permet de recuperer le chemin vers la fonction ?

---

Les codes soures de la libC qui sont du domaine du libre...

Citation:

---

Envoyé par dalfab

Et attention de ne pas apprendre un C trop ancien. Denis Ricchie est mort depuis quelques années et Kernighan n'est plus tout jeune. Le C bouge peu, mais en 40 ans il peut se passer des choses.

---

Enfin je dirais qu'il y'a pas mal de choses qui ont bougé depuis le " Le langage C " de Kernighan&Ritchie , surtotu si on regarde les rajout niveau lib stantard.

Sinon même sans parler de la lib stantard , les principaux reproche qu'on pourrait faire seront les suivant :
-pas de commentaire à la C++ (donc sur une ligne avec // )
-les variables sont uniquement au début (alors qu'il est conseillé de les faire au plus proche de leur utilisation )
-le code présenter est assez "mauvais" , dans le sens où c'est pour aider des compilateurs anciens , mais de nos jours codé de cette façon ralentirai plus le compilo qu'autre chose ( plus le code est clair , plus le compilo optimisa aux mieux ).

Pour la directive extern :

Commençons par quelques explications.

le principe de compilation :
Chaque fichier .c est compilé à part en fichier objet .o.
L'éditeur de lien appelé par le compilateur va ensuite générer l'exécutable en regroupant tous les fichiers .o et en recopiant dans le code les fonctions des bibliothèques statiques, et/ou en ajoutant les liens aux fonctions contenues dans les bibliothèques dynamiques.

Quand du déclare une fonction dans ton code, tu lui définie (ou non) des paramètres, et tu définie aussi le type de la variable de retour de la fonction (si elle retourne quelque chose). C'est ce qu'on appelle son prototype (en quelque sorte sa signature).

Plus loin dans ton code, quand tu appelle cette fonction, le compilateur va vérifier que ton appel correspond au prototype. Exemple: si ta fonction attend un int en paramètre et que tu lui passes autre chose, le compilo va gueuler.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int ma_fonction (int parametre) { ... return 0; }   int main() { int valeur; char caractere; int retour=ma_fonction(caractere); //generera une erreur car la fonction "fonction" attend un int pas un char int retour=ma_fonction(valeur);

---

Imagines maintenant que ta fonction "ma_fonction" soit dans le fichier fonctions.c et que ton code principal se trouve dans main.c. Comme expliqué main.c et fonctions.c seront compilés distinctement. Que va t'il se passer ? main.c ne connaissant pas le prototype de ta fonction "ma_fonction", le compilateur ne la connaitra pas pour main.c.
Pour cela on créera un fichier d'entête contenant la signature de la fonction :

Code:

---

1 2 3

//fichier fonctions.h int ma_fonction (int parametre);

---

En ajoutant :

Code:

---

#include "fonctions.h";

---

dans main.c, le compilateur intègrera ce .h à main.c et aura donc la signature de la fonction et pourra compiler.
Les "include guards" dont on t'a parlé servent à éviter que l'utilisation de .h insèrent plusieurs fois leut contenu dans des .c lors de la compilation.

Pourquoi mettre des fonctions dans plusieurs fichiers c ? Si tu modifie une seule fonction, tu n'auras pas besoin de recompiler tout le projet, juste le .c concerné (il faudra bien sur régénérer l’exécutable). tu gèrera cela plus tard avec des Makefile.

Tu as vu ou tu verras la portée des variables. Une variable déclarée dans une fonction ne sera utilisable que dans cette fonction, on parlera de variable locale. Une variable déclarée en début de ton code et pas dans une fonction sera une variable accessible dans tout ton code, on parlera de variable globale.
Nous allons enfin arriver à l'usage de extern.
Imagines que tu es une variable globale déclarée ans ton fichier principal main.c et que tu souhaites l'utiliser dans ton fichier fonctions.c. tu vas déclarer normalement ta variable exemple :

Code:

---

int superglobale=0;

---

Tu vas ensuite la déclarer dans ton fichier d'entête fonctions.h avec extern :

Code:

---

extern int superglobale;

---

tout fichier .c intégrant l'en-tête fonctions.h pourra utiliser cette variable. Attention la variable doit être déclarée une fois et une seule fois dans tous les fichiers, la déclaration extern indiquant de quelle type elle est mais ne vérifiant pas si elle a été déclarée. C'est une pratique dangereuse et dont tu as rarement besoin.

Citation:

---

Envoyé par chrtophe

exemple :

Code:

---

int superglobale=0;

---

Tu vas ensuite la déclarer dans ton fichier d'entête fonctions.h avec extern :

Code:

---

extern int superglobale;

---

tout fichier .c intégrant l'en-tête fonctions.h pourra utiliser cette variable.

---

Il existe une autre façon d'utiliser extern, façon moins connue mais qui gagnerait à l'être: c'est dans une fonction pour indiquer qu'on va utiliser une globale.

Exemple

Code:

---

1 2 3 4 5 6 7 8 9

int superglobale=0;   ...(plein de code divers et varié)...   void increment(int n) { extern int superglobale;   superglobale+=n; }

---

Dans l'absolu, on est bien d'accord que cette déclaration extern dans la fonction n'est pas obligatoire. Toutefois c'est autorisé et ça permet d'indiquer de façon assez lisible que la fonction va utiliser (et potentiellement modifier) cette globale. En effet, un des plus gros soucis des globales c'est quand elle est modifiée par accident (en réalité par erreur de programmation) et retrouver qui l'a modifiée. Cette façon de faire permet d'aider en cas de recherche.

Citation:

---

Envoyé par chrtophe

Attention la variable doit être déclarée une fois et une seule fois dans tous les fichiers

---

Par facilité on la déclare dans le fichier qui contient le main()

C'est moi qui chauffe à la compilation maintenant , ça fait beaucoup d'infos à ingerer :)

J'essaye de dresser un tableau recapitulatif :

Un programme en C est modulaire , son axe est le main.c. Une fonction peut être soit integrée au -main-, soit deportée ( et donc doit être liée ) dans un autre .c, soit deportée et integrée à un ensemble de fonction qui devient un .lib par exemple. Le .h indique au compilateur comment preparer l'acces aux parametres de la fonction - si elle est deportée - ( j'imagine qu'il est question de gestion memoire , registres ) et si besoin , le lien vers le code de la fonction ( ce qui permet à l'éditeur de lien de faire...le lien ? ) << à moins que ce ne soit l'OS du systeme qui gere le chemin vers le code de la fonction ?

Citation:

---

Envoyé par dhuasca

J'essaye de dresser un tableau recapitulatif

---

Ok, avec un exemple complet ça ira mieux
Prenons un programme tout simple qui calcule un carré et un cube. Tout d'abord, et c'est assez naturel, tu l'écriras d'une traite

Code:

---

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

// Fonction carré unsigned long carre(short nb){ return((long)nb * nb); }   // Fonction cube long cube(short nb) { return((long)nb * nb * nb); }   // Fonction principale int main() { printf("Carré de 2 = %lu\n", carre(2)); printf("Cube de 3 = %ld\n", cube(3)); }

---

Et pour le compiler (imaginons que tu l'aies appelé "prog.c"): gcc prog.c -o prog.

Ensuite, tu te dis que ce programme est difficile à maintenir parce que trop gros (oui là il n'y a que 2 fonctions mais il pourrait y en avoir 50). Tu vas donc le découper en plusieurs sources
carre.c

Code:

---

1 2 3 4

// Fonction carré unsigned long carre(short nb){ return((long)nb * nb); }

---

cube.c

Code:

---

1 2 3 4

// Fonction cube long cube(short nb) { return((long)nb * nb * nb); }

---

Et prog.c. Toutefois là un petit souci: comme lui il va utiliser des fonctions qu'il ne connait pas (il n'a plus le source des fonctions) on doit les déclarer pour que le compilateur sache qu'elles existent ailleurs

Code:

---

1 2 3 4 5 6 7 8 9

// Prototypes des fonctions afin que le compilateur les connaisse avant de les utiliser unsigned long carre(short); long cube(short);   // Fonction principale int main() { printf("Carré de 2 = %lu\n", carre(2)); printf("Cube de 3 = %ld\n", cube(3)); }

---

Et la compilation

Code:

---

1 2 3

gcc -c carre.c gcc -c cube.c gcc prog.c carre.o cube.o -o prog

---

Ensuite tu te dis que c'est pas mal ces fonctions carre et cube et que d'autres dev pourraient les utiliser aussi. Mais dans ce cas il sera plus pratique si tu les regroupes ensemble dans un gros truc qu'on appelle "librairie". Ainsi récupérer "un" gros truc sera plus simple pour les autres dev que récupérer 2, 3, 50 petits trucs.
Les sources ne changent pas, seule change la compilation dans laquelle tu commences par créer la librairie que tu vas appeler "math.a"

Code:

---

1 2 3

gcc -c carre.c gcc -c cube.c ar rv math.a carre.o cube.o

---

(bon là mon exemple date un peu et il se peut que la commande de création ait un peu changé et malheureusent je ne suis pas chez-moi et n'ai pas possibilité de tester et vérifier la syntaxe de cette commande "ar" mais le principe lui ne change pas, compilation des sources et regroupement en une librairie)

Une fois la librairie créée, tu peux l'intégrer dans ton programme final: gcc prog.c math.a -o prog.

Il ne reste plus qu'à faciliter la vie des autres qui, pour utiliser ta librairie, devront aussi prévenir leur propre compilateur de l'existence des fonctions "carre" et "cube". Et pour ne pas qu'ils aient à écrire ces prototypes, c'est toi qui les écrit dans ce qu'on appelle un "header" (en-tête) que les autres dev pourront récupérer et intégrer dans leur code, header que tu nommes "math.h" en référence à ta librairie "math.a"

Code:

---

1 2 3 4 5 6 7 8

// Bloc conditionnel au cas où "math.h" serait inclus par un autre header (idempotence) #ifndef _MATH_H_ // Si "_MATH_H_" non défini #define _MATH_H_ // Définition "_MATH_H_"   // Fonctions mathématiques unsigned long carre(short); long cube(short); #endif /* _MATH_H_*/ // Fin de bloc conditionnel "_MATH_H_"

---

Ensuite, un autre dev récupère "math.a" et "math.h" et peut utiliser ta librairie dans son propre code

Code:

---

1 2 3 4 5 6 7

#include "math.h" // Fonctions mathématiques   // Fonction principale int main() { printf("Carré de 2 = %lu\n", carre(2)); printf("Cube de 3 = %ld\n", cube(3)); }

---

Et la compilation: gcc prog.c math.a -o prog.

Et un schéma qui résume tout ça
Pièce jointe 600137
Le ".i" c'est l'interprété (tous les headers et #define ont été intégrés). Le ".s" c'est l'assembleur et le ".o" c'est le code objet compilé.

Je vous remercie BEAUCOUP , j'ai largement de quoi continuer à avancer. C'est beaucoup plus clair quand on a accès à la cinématique du processus :)

Je mets le post en "résolu" , passez une bonne journée !