Programmation C/Fonctions et procédures
Définition.
Le code suivant définit une fonction codice_1 renvoyant une valeur de type codice_2 et prenant N arguments, codice_3 de type codice_4, codice_5 de type codice_6, etc.
type_retour fonction(type1 par1, type2 par2, /* ..., */ typeN parN) 
 /* Déclarations de variables ... */
 /* Instructions ... */
L'exécution d'une fonction se termine soit lorsque l'accolade fermante est atteinte, soit lorsque le mot clef codice_7 est rencontré. La valeur renvoyée par une fonction est donnée comme paramètre à codice_7.
Une procédure est une fonction renvoyant codice_9, dans ce cas codice_7 est appelé sans paramètre.
Les passages des arguments aux fonctions se font toujours "par valeur". Si on veut modifier la valeur d'un argument passé en paramètre à une fonction, en dehors de cette même fonction, il faut utiliser des pointeurs.
Déclaration par prototype.
Le prototype d'une fonction correspond simplement à son en-tête (tout ce qui précède la première accolade ouvrante). C'est-à-dire son nom, son type de retour et les types des différents paramètres. Cela permet au compilateur de vérifier que la fonction est appelée avec le bon nombre de paramètres et surtout avec les bons types. La ligne suivante "déclare" la fonction codice_1, mais sans la "définir" :
type_retour nom_fonction(type1, type2, /* ..., */ typeN);
À noter que les noms des paramètres peuvent être omis et que la déclaration doit se terminer par un point-virgule (;), sans quoi vous pourrez vous attendre à une cascade d'erreurs.
Absence des paramètres.
Avant la normalisation par l'ANSI, il était possible de faire une déclaration partielle d'une fonction, en spécifiant son type de retour, mais pas ses paramètres:
int f();
Cette déclaration ne dit rien sur les éventuels paramètes de la fonction codice_12, sur leur nombre ou leur type, au contraire de :
int g(void);
qui précise que la fonction codice_13 ne prend aucun argument.
Cette déclaration partielle laissait au compilateur le soin de compléter la déclaration lors de l'appel de la fonction, ou de sa définition. On perd donc un grand intérêt des prototypes. Mais à cause de "l'immense" quantité de code existant qui se reposait sur ce comportement, l'ANSI (puis le WG14) n'ont pas interdit de tels programmes, mais ont déclaré dès le C90 que cette construction est "obsolète".
Évaluation des arguments.
La norme du langage ne spécifie pas l'ordre d'évaluation des arguments. Il faut donc faire particulièrement attention aux effets de bords. 
int somme(int a, int b)
int main(void)
 int i = 0;
 printf("%d\n", somme(++i, i) );
 return 0;
Voici un premier exemple. Lors de l'appel de la fonction codice_14, si l'expression codice_15 est évaluée avant l'expression codice_16, alors le programme affichera "2". Si, au contraire, c'est l'expression codice_16 qui est évaluée avant l'expression codice_15, alors le programme affichera "1".
int fonction(int, int);
int g(void);
int h(void);
int test(void)
 return fonction(g(), h());
Dans cet autre exemple, les expressions codice_19 et codice_20 pouvant être évaluées dans n'importe quel ordre, on ne peut pas savoir laquelle des fonctions codice_13 et codice_22 sera appelée en premier. Si l'appel de ces fonctions provoque des effets de bord (affichage de messages, modification de variables globales...), alors le comportement du programme est imprévisible. Pour pallier à ce problème, il faut imposer l'ordre d'appel :
int fonction(int, int);
int g(void);
int h(void);
int test(void)
 int a,b;
 a = g();
 b = h();
 return fonction(a, b);
Nombre variable d'arguments.
Une fonctionnalité assez utile est d'avoir une fonction avec un nombre variable d'arguments, comme la fameuse fonction codice_23. Pour cela, il suffit de déclarer le prototype de la fonction de la manière suivante :
Déclaration.
void ma_fonction(type1 arg1, type2 arg2, ...)
Dans l'exemple ci-dessus, les points de suspension ne sont pas un abus d'écriture, mais bel et bien une notation C pour indiquer que la fonction accepte d'autres arguments. L'exemple est limité à deux arguments, mais il est bien sûr possible d'en spécifier autant qu'on veut. C'est dans l'unique but de ne pas rendre ambigüe la déclaration, qu'aucun abus d'écriture n'a été employé.
L'inclusion de l'en-tête codice_24 n'est nécessaire que pour traiter les arguments à l'intérieur de la fonction. La première remarque que l'on peut faire est qu'une fonction à nombre variable d'arguments contient au moins un paramètre fixe. En effet la déclaration suivante est invalide :
void ma_fonction(...);
Accès aux arguments.
Pour accéder aux arguments situés après le dernier argument fixe, il faut utiliser certaines fonctions (ou plutôt macros) de l'en-tête codice_24 :
void va_start (va_list ap, last);
type va_arg (va_list ap, type);
void va_end (va_list ap);
codice_26 est un type opaque dont on n'a pas à se soucier. On commence par l'initialiser avec codice_27. Le paramètre codice_28 doit correspondre au nom du dernier argument fixe de la fonction, ou alors tout bon compilateur retournera au moins un avertissement.
Vient ensuite la collecte "minutieuse" des arguments. Il faut bien comprendre qu'à ce stade, le langage n'offre aucun moyen de savoir comment sont structurées les données (c'est à dire leur type). Il faut absolument définir une convention, laissée à l'imagination du programmeur, pour pouvoir extraire les données correctement.
Qui plus est, il faut être extrêmement vigilant lors de la récupération des paramètres, à cause de la promotion des types entiers ou réels. En effet, les entiers sont systématiquement promus en codice_29, sauf si la taille du type est plus grande, auquel cas le type est inchangé. Pour les réels, le type codice_30 est promu en codice_31, alors que le type codice_32 est inchangé. C'est pourquoi ce genre d'instruction n'a aucun sens dans une fonction à nombre variable d'arguments :
char caractere = va_arg(list, char);
Il faut obligatoirement récupérer un entier de type codice_33, comme étant un entier de type codice_29.
Exemple de convention.
Un bon exemple de convention est la fonction codice_23 elle même. Elle utilise un spécificateur de format qui renseigne à la fois le nombre d'arguments qu'on s'attend à trouver mais aussi le type de chacun. D'un autre côté, analyser un spécificateur de format est relativement rébarbatif, et on n'a pas toujours besoin d'une artillerie aussi lourde.
Une autre façon de faire, relativement répandue, est de ne passer que des couples (type, objet), où codice_36 correspond à un code représentant un type (une énumération par exemple) et codice_37 le contenu de l'objet lui-même (codice_29, pointeur, codice_31, etc.). On utilise alors un code spécial (généralement 0) pour indiquer la fin des arguments, ou alors un des paramètres pour indiquer combien il y en a. Un petit exemple complet :
enum va_list{
 TYPE_FIN, TYPE_ENTIER, TYPE_REEL, TYPE_CHAINE
void affiche(FILE * out, ...)
 va_list list;
 int type;
 va_start(list, out);
 while ((type = va_arg(list, int)))
 switch (type)
 case TYPE_ENTIER: fprintf(out, "%d", va_arg(list, int)); break;
 case TYPE_REEL: fprintf(out, "%g", va_arg(list, double)); break;
 case TYPE_CHAINE: fprintf(out, "%s", va_arg(list, char *)); break;
 fprintf(out, "\n");
 va_end(list);
int main(int nb, char * argv[])
 affiche(stdout, TYPE_CHAINE, "Le code ascii de 'a' est ", TYPE_ENTIER, 'a', 0);
 affiche(stderr, TYPE_CHAINE, "2 * 3 / 5 = ", TYPE_REEL, 2. * 3 / 5, 0);
 return 0;
L'inconvénient de ce genre d'approche est de ne pas oublier le marqueur de fin. Dans les deux cas, il faut être vigilant avec les conversions implicites, notamment dans le second cas. À noter que la conversion (transtypage) explicite des types en une taille inférieure à celle par défaut (codice_29 pour les entiers ou codice_31 pour les réels) ne permet pas de contourner la promotion implicite. Même écrit de la sorte:
affiche(stderr, TYPE_CHAINE, "2 * 3 / 5 = ", TYPE_REEL, (float) (2. * 3 / 5), 0);
Le résultat transmis au cinquième paramètre sera quand même promu implicitement en type codice_31.
Fonction "inline".
Il s'agit d'une extension ISO C99, qui à l'origine vient du C++. Ce mot clé doit se placer avant le type de retour de la fonction. Il ne s'agit que d'une indication, le compilateur peut ne pas honorer la demande, notamment si la fonction est récursive. Dans une certaine mesure, les fonctionnalités proposées par ce mot clé sont déjà prises en charge par les instructions du préprocesseur. Beaucoup préfèreront passer par une macro, essentiellement pour des raisons de compatibilité avec d'anciens compilateurs ne supportant pas ce mot clé, et quand bien même l'utilisation de macro est souvent très délicat.
Le mot clé codice_43 permet de s'affranchir des nombreux défauts des macros, et de réellement les utiliser comme une fonction normale, c'est à dire surtout sans effets de bord. À noter qu'il est préférable de classifier les fonctions codice_43 de manière statique. Dans le cas contraire, la fonction sera aussi déclarée comme étant accessible de l'extérieur, et donc définie comme une fonction normale.
En la déclarant codice_45, un bon compilateur devrait supprimer toute trace de la fonction et seulement la mettre "in extenso" aux endroits où elle est utilisée. Ceci permettrait à la limite de déclarer la fonction dans un fichier en-tête, bien qu'il s'agisse d'une pratique assez rare et donc à éviter. Exemple de déclaration d'une fonction codice_43 statique :
static inline int max(int a, int b)
 return (a > b) ? a : b;
La fonction main.
Nous allons revenir ici sur la fonction codice_47, présente dans chaque programme. Cette fonction est le point d'entrée du programme. La norme définit deux prototypes, qui sont donc portables:
Le premier prototype est plus "général" : il permet de récupérer des paramètres au programme. Le deuxième existe pour des raisons de simplicité, quand on ne veut pas traiter ces arguments.
Si ces deux prototypes sont portables, une implémentation peut néanmoins définir un autre prototype pour codice_47, ou spécifier une autre fonction pour le démarrage du programme. Cependant ces cas sont plus rares (et souvent spécifiques à du C embarqué).
Paramètres de ligne de commande.
La fonction codice_47 prend deux paramètres qui permettent d'accéder aux paramètres passés au programme lors de son appel. Le premier, généralement appelé codice_50 ("argument count"), est le nombre de paramètres qui ont été passés au programme. Le second, codice_51 ("argument vector"), est la liste de ces paramètres. Les paramètres sont stockés sous forme de chaîne de caractères, codice_51 est donc un tableau de chaînes de caractères, ou un pointeur sur un pointeur sur codice_33. codice_50 correspond au nombre d'éléments de ce tableau.
La première chaîne de caractères, dont l'adresse est dans codice_55, contient le nom du programme. Le premier paramètre est donc codice_56. Le dernier élément du tableau, codice_57, est un pointeur nul.
Valeur de retour.
La fonction codice_47 retourne toujours une valeur de type entier. L'usage veut qu'on retourne 0 (ou codice_59) si le programme s'est déroulé correctement, ou codice_60 pour indiquer qu'il y a eu une erreur (Les macros codice_59 et codice_60 étant définies dans l'en-tête codice_63). Il est possible par le programme appelant de récupérer ce code de retour, et de l'interpréter comme bon lui semble.
Particularités.
Cette fonction ignore les prototypes, il n'est pas non plus nécessaire d'en écrire pour elle. On dit que l'environnement fournit ses prototypes mais cela n'est pas vraiment exact car une fonction en C ne peut avoir qu'un seul prototype. Cet exemple compilera
char main(int arg1, char arg2, double arg3) {
 return 0;
Elle ignore également le type de retour, le programme compilera si votre fonction main ne contient pas d'instruction return ou une instruction return qui ne correspond pas à son prototype. Par défaut dans un environnement UNIX une fonction main qui ne contient pas d'instruction return retournera 0, signifiant que le programme s'est exécuté correctement. Les deux programmes suivant sont équivalents
int main() {
 /* pas d'instruction return */
int main() {
 return 0;
Il est possible d'appeler la fonction main récursivement en C mais cela est interdit en C++, pour une portabilité maximale, il faut éviter de le faire.
int main(int argc, char** argv) {
 main(argc, argv); // interdit en c++
Exemple.
Voici un petit programme très simple qui affiche la liste des paramètres passés au programme lorsqu'il est appelé:
int main(int argc, char * argv[])
 int i;
 for (i = 0; i < argc; i++)
 printf("paramètre %i : %s\n", i, argv[i]);
 return 0;
On effectue une boucle sur codice_51 à l'aide de codice_50. Enregistrez-le sous le nom codice_66 puis compilez-le (codice_67). Vous pouvez ensuite l'appeler ainsi:
Vous devriez voir en sortie quelque chose comme ceci ("paramètre 0" varie selon le système d'exploitation):
Fonctions en C pré-ANSI.
Absence de prototype lors de l'appel d'une fonction.
Avant la normalisation C89, on pouvait appeler une fonction sans disposer ni de sa définition, ni de sa déclaration. Dans ce cas, la fonction était "implicitement" déclarée comme retournant le type codice_29, et prenant un nombre indéterminé de paramètres.
/* Aucune déclaration de g() n'est visible. */
void f(void)
 g(); /* Déclaration implicite: extern int g() */
À cause de la grande quantité de code existant à l'époque qui reposait sur ce comportement, le C90 a conservé cette possibilité. Cependant, elle a été retirée de la norme C99, et est à éviter même lorsqu'on travaille en C90.
En effet, c'est plus qu'une bonne habitude de programmation de s'assurer que "chaque" fonction utilisée dans un programme ait son prototype déclaré avant qu'elle ne soit définie ou utilisée. C'est d'autant plus indispensable lorsque les fonctions sont définies et utilisées dans des fichiers différents.
Ancienne notation.
À titre anecdotique, ceci est la façon « historique » de définir une fonction, avant que le prototypage ne fut utilisé. Cette notation est interdite depuis C90.
type_retour fonction(par1, par2, ..., parN)
type1 par1;
type2 par2;
typeN parN;
 /* Déclarations de variables ... */
 /* Instructions ... */
Au lieu de déclarer les types à l'intérieur même de la fonction, ils sont simplement décrits après la fonction et avant la première accolade ouvrante. À noter que codice_2 "pouvait" être omis, et dans ce cas valait par défaut codice_29.
Fichiers.
Exécuter des fichiers.
Les primitives sont "execl, execlp, execle, exect, execv, execvp".
L'exemple ci-dessous lance un fichier "test.exe" sur un bureau de Windows 7 :
int main()
 int fichier;
 fichier = execl ( "c:\\Users\\public\\Desktop\\test.exe", "test.exe", ".", (char*)0);
Renommer et supprimer des fichiers.
Utiliser la fonction "rename" (appel système) pour renommer un fichier.
Utiliser "remove" (bibliothèque C, tous types de fichiers) ou "unlink" (appel système pour supprimer un fichier) et "rmdir" (appel système pour supprimer un répertoire).
Attention, "remove", "unlink" et "rmdir" ne suppriment pas réellement le fichier ou répertoire, mais uniquement un nom (lien statique ou "dur" (hardlink)) dudit fichier ou répertoire. Si le nom en question est le dernier nom du fichier ou répertoire, alors le système de fichiers n'a plus de référence vers le fichier qui n'est dès lors plus accessible et l'espace qu'il occupait est disponible pour d'autres fichiers. Les données ne sont aucunement effacées, seul le lien permettant d'y accéder est détruit. Si le fichier avait plusieurs noms il reste accessible par ses autres noms. La commande "ln ancien_nom nouveau_nom" permet de donner un nom supplémentaire "nouveau_nom" au fichier "ancien_nom".
Copier des fichiers.
Il faut copier le contenu du premier dans le second.