Discussion :

[dhuasca]

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 !

[foetus]

Mais où est le code de la fonction ?

Dans les fichiers source .c

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 , 1 fonction est toujours externe, donc la mettre en extern ne sert à rien.

[dalfab]

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.

[WhiteCrow]

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».

[Kannagi]

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 ).

[Christophe]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
//fichier fonctions.h
int ma_fonction (int parametre);

En ajoutant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#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 :

Sélectionner tout - Visualiser dans une fenêtre à part

int superglobale=0;

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Sve@r]

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int superglobale=0;

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 c :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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()

[dhuasca]

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 ?

[sambia39]

Bonjour,

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.

[dhuasca]

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 ?

[foetus]

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 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 qu'il y a 1 différence entre #include "stdio.h" (recherche locale) et #include <stdio.h> (recherche dans les chemins connus)

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 il faudrait chercher

Edit: @WhiteCrow a donné 1 lien

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
Comme je l'ai dit, c'est pour ne pas divulguer le code.

[WhiteCrow]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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")

[Sve@r]

Bonjour

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.

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...