Voilà quelques temps que je n’avais plus utilisé ce média ; j’avais posté un article similaire sur une plateforme perdue, mais, n’ayant pas reçu réellement de retour, je me suis dit qu’il serait intéressant de centraliser tous mes petits articles ici, de manière à renvoyer uniformément les visiteurs sur cette page. Au départ, il s’agissait ici de parler uniquement de programmation système ; le sort en a décidé autrement.

En attendant, vous allez devoir me pardonner pour cette digression, qui ne devrait pas vraiment avoir de répercussion sur les visites, ceci dit. Voilà une nouvelle catégorie, « Divers », qui devrait accueillir nombre de mes réflexions inutiles (sur les forums, il est difficile de se lâcher sans se faire taper sur les doigts).

Qu’on se mette d’accord, aujourd’hui, c’est d’un véritable phénomène qu’on va parler. Une habitude étrange que quelques débutants ont prise : effectuer une récursion sur la fonction main. Ce sera notre prétexte pour explorer tout le vaste sujet de la récursivité en C. Je ne sais pas qui le leur a inculqué (ou plutôt, qui n’a pas fait son boulot en le leur empêchant) ; toujours est-il que cela fait frémir la plupart des programmeurs « habitués » sur les forums. Si ce n’est pas votre cas, c’est inquiétant. Du moins, on va essayer de voir si c’est le cas. Et surtout, pourquoi.

Une récursion pour les trouver

Vous êtes ici, sur un billet qui parle du C, et on vous parle d’algorithmique ? Voilà qui semble, à première vue, plutôt contradictoire. Après tout, les gens qui font du C sont plutôt branchés sur le matériel. C’est ça, le (faux) bas niveau. Seulement, la récursivité, c’est, avant toute chose, une manière particulière de définir un algorithme donné, en le définissant par rapport à une entrée plus simple du problème. En programmation, on parlera de récursivité lorsqu’une fonction s’appelle elle-même. Parfois, il y a même des cas de récursivité croisée, ou deux fonctions s’appellent mutuellement. Un exemple plutôt connu est la suite d’Hofstadter.

Prenons maintenant l’exemple (sérieux) d’un algorithme calculant la factorielle d’un nombre entier naturel. Vous pouvez la définir de deux manières différentes :

1) Itérativement : n! = 1 * 2 * … * n.

2) Récursivement : n! = 1 si n = 0 et n * (n – 1)! si n > 0.

Dès ces cas d’école, les puristes commencent à remettre en cause l’efficacité de la solution récursive. En effet, par nature, le C est assez proche de la machine. Chaque appel de fonction nécessite, en théorie, la création d’un cadre de pile (en pratique, certaines de ces fonctions peuvent être inlinées par le compilateur, c’est-à-dire en ajoutant le code directement dans la fonction appelante).

Ce n’est pas une opération particulièrement légère, et, dès qu’on se met à penser à la micro-optimisation, il vaut mieux éviter. En dehors de la performance, cela pose un autre problème : celui de la mémoire. Il faut bien voir que toutes les variables automatiques, les registres de base et de retour notamment, doivent être stockés sur la pile, et ce pour chaque récursion en cours.

En conséquence, le compilateur essaye de transformer des cas récursifs simples en boucles (qui, au final, auront l’air d’un branchement inconditionnel, équivalent à un vulgaire goto). Il est bien connu que tout appel récursif peut être converti en itératif, par l’intermédiaire de piles (en recodant la pile d’appels en fait), mais, naturellement, ça n’aurait pas de sens pour le compilateur de faire ce genre d’optimisations. Cependant, supposez que vous ayez choisi de coder la factorielle de cette manière :

Parce que r indique les résultats de la récursivité au fur et à mesure, on dit qu’il sert d’accumulateur. En outre, on remarque ici que l’appel récursif peut être facilement évité : il suffit de changer la valeur de r et de n à chaque fin de branchement. Mettons-nous à la place du compilateur optimisant (c’est le cas de la plupart des compilateurs « grands publics » comme gcc, clang ou icc). Voilà comment il pourrait réécrire le code.

Je ne suis pas certain que beaucoup d’entre vous aimerait maintenir ce genre de code, mais, pour la bêtise absolue d’un ordinateur, ce n’est pas dérageant. Au contraire, comme sa fainéantise est légendaire, il va se réjouir de pas avoir à créer un nouveau cadre de pile à chaque fois qu’on décrémente n. On parle dans ce cas de récursivité terminale, et ce n’est pas le cas de la fonction factorial_2 ci-dessus. Bref, tout ça pour dire quoi ? Que la récursivité, c’est intrinsèquement de l’algorithmique. Ça fait plaisir aux férus de la programmation fonctionnelle, mais ça ne devrait pas atteindre nos points d’entrée… Enfin, en théorie.

Une récursion pour les amener tous

Venons-en au fait. Enfin, presque. Oui, parce que je voulais vous présenter mon nouveau jeu en console puissant. Du coup, j’ai fait une jolie interface avec une fonction juste pour le menu. Voilà à quoi ressemble notre bête :

Sauf que, si je laisse ça comme ça, il y a danger. Danger que la pile explose, en réalité. Elle a une taille limitée, et un utilisateur malicieux pourrait même exploiter ces débordements pour écrire par-dessus certaines données (mais ça rentre dans des techniques d’exploitation plutôt sordides). Dans une certaine mesure, même dans les langages fonctionnels (oui, oui), on évite généralement les systèmes récursifs pour lire des données structurées comme les tableaux. Pour les listes ou les arbres, c’est différent, mais, même en C, la question se pose.

En fait, toutes ces histoires de puristes restent extrêmement subjectives. Notre fonction menu ci-dessus croît selon un majorant en O(n). En revanche, il existe certaines fonctions qui ont une complexité bien moindre. C’est par exemple le cas de la recherche dichotomique, qui permet de rechercher une valeur dans un tableau trié en complexité logarithmique (par le biais du paradigme « diviser pour régner »). Ainsi, cela ne posera pas trop de problème à un programmeur d’écrire :

Pourtant, la solution itérative est tout aussi limpide. Du coup, la récursivité se justifie encore plus facilement quand on est obligé de sortir un modèle à base de pile pour la conversion. C’est par exemple le cas des parsers d’expression, quand on doit explorer des caractères sémantiques par définition récursifs (comme les parenthèses dans un parser d’expressions mathématiques).

… et dans les ténèbres les lier

Il est temps de discuter ce qui devait être notre objet initial, mais, qui, finalement, est passé au travers de ma langue bavarde. Oui, parce qu’il existe des pauvres fous (fuyez !) qui, non contents de faire de la récursion sur des menus, le font dans la fonction main ! On voit quelques fois un exemple de récursivité croisée, quand les débutants veulent revenir au début du programme, alors qu’ils sont perdus dans des structures conditionnelle imbriquées.

Le mieux, dans ce genre de code, c’est de passer à la boucle (en ré-arrangeant le code dans un premier temps, évidement…) ; cela pour deux raisons majoritairement :

Pour finir, j’aimerais simplement vous montrer un petit contre-exemple, que quelqu’un proposait sur Usenet. Le principe est d’utiliser la récursivité sur la fonction main pour simplifier le traitement des arguments en ligne de commande. Personnellement, je n’ai jamais eu affaire à ce genre de contraintes, mais on ne sait jamais sur quoi on peut tomber (sans getopt, certains sont perdus !).

Voilà qui clôt magistralement mal notre modeste billet. J’espère ne pas trop vous avoir ennuyé, et n’oubliez pas de rediriger le prochain inconscient par ici… non sans l’avoir châtié sévèrement, évidemment !

PS : Comme habituellement, ça fait toujours du plaisir de voir ses posts commentés… Même si vous n’avez rien à dire, ça donne l’impression qu’on ne parle pas dans le vide. Sauf si vous ne voulez plus jamais me voir appuyer sur une touche du clavier, auquel cas je vous laisse déverser votre haine dans le silence. Le train de vos injures roule sur les rails de mon indifférence, disait un proverbe populaire.

– son PID ;
– son PPID ;
– son état ;
– son contexte processeur (état des registres) et mémoire (adresses de l’espace d’adressage) ;
– ses critères d’ordonnancement ;
– les fichiers ouverts.

– élu ;
– bloqué ;
– prêt.

Un processus est dans l’état élu lorsqu’il s’exécute, après avoir obtenu le processeur.
Il est bloqué lorsqu’il est en attente, par exemple d’une lecture de disque.
Il est dans l’état prêt lorsqu’il est n’est pas en attente, mais qu’il n’a pas le processeur. Il attend simplement que ce soit son tour.

Le passage de l’état prêt à l’état élu constitue l’opération d’élection.
Le passage de l’état élu à l’état bloqué constitue l’opération de blocage.
Le passage de l’état bloqué à l’état prêt constitue l’opération de déblocage.

Deux ypes de fonction permettent la programmation système :
– les fonctions de la bibliothèque standard de C (libc) ;
– les appels-systèmes, fonctions d’interface entre le noyau et les applications. Lors de son appel, le noyau effectue un déroutement (trap) qui bascule en mode noyau.

Cet appel-système alloue un bloc de contrôle dans la table des processus, copie certaines des informations du bloc du père (fichiers ouverts, répertoire courant, etc.) dans le bloc du fils. Il alloue un PID au processus fils.
Le noyau alloue le segment texte du processus, dans lequel il place son code. Le segment de données et la pile ne seront alloués que plus tard, lorsque l’utilisateur tentera de les utiliser. Cette technique, appelée copy on write, permet de réduire les coûts de l’allocation. Enfin, l’état du processus est mis à la valeur exécution.

void exit(int status);

de stdlib.h.

status est un entier, qui permet d’indiquer la valeur de retour du processus. Conventionnellement, on utilise la valeur de 0 pour indiquer une sortie correcte, ou une autre valeur pour indiquer l’erreur. Exemple :

On pourra récupérer la valeur envoyée à exit par un processus fils par son processus père, et ce sera l’objet d’un prochain article plus complet, concernant la synchronisation des processus.

En pratique, les variables d’environnement sont des chaînes de caractère sous la forme NOM=VALEUR. Elles sont modifiées par les fichiers d’initialisation du shell par exemple.

Pour accéder aux variables d’environnement d’un processus dans un programme codé en C, il suffit d’utiliser le tableau environ, une variable globale. Il faut le déclarer en début de programme car il n’est pas définit dans les fichiers d’en-têtes standards.

extern char **environ;

Il contient des chaînes de caractères se terminant par le caractère ‘\0′, et se termine lui-même par un pointeur nul.

Exemple de programme listant les variables d’environnement du processus principal.

Notez qu’il existe également une autre solution pour lister les variables d’environnement du processus principal, bien que moins recommandée. En effet, il est possible d’utiliser un troisième argument de la fonction main(), envp, qui se comporte comme environ. Exemple :

Bon codage !

Après avoir introduit la création des processus, je souhaitais vous présenter quelques fonctions qui sont utiles, notamment lors du débogage de votre application.

Je cite :

pid_t getpid(void);

qui retourne le PID du processus courant.

pid_t getppid(void);

qui retourne le PID du processus père du processus courant.

uid_t getuid(void);

qui retourne l’UID (identificateur de l’utilisateur qui a créé le processus) du processus courant.

gid_t getgid(void);

qui retourne le GID (identificateur du groupe auquel appartient l’utilisateur) du processus courant.

Exemple qui résument les fonctions que je viens de vous présenter :

Bon codage !

Dans ce billet, qui est le premier de ce blog, je souhaitais vous présenter mon projet. Je suis passionné par la programmation en C, et plus particulièrement par l’aspect « bas niveau » de celle-ci. Le C a été créé pour développer le système d’exploitation UNIX, sur lequel sont basés la plupart des OS couramment usés.
La programmation système consiste au développement d’applications qui font partie intégrante du système d’exploitation. C’est ce type de programmation, opposée aux programmes utilisateurs, que je voulais vous faire découvrir dans ce blog.

Ce premier billet commence par la pratique, et avec la création des processus. Les processus représentent l’image d’un programme à un instant donné (état des registres entres autres).

Chaque processus possède un espace d’adressage donné, dans lequel il peut lire et écrire. Cet espace est divisé en trois grandes parties (segment texte, segment données, pile).

En C et sous un système d’exploitation basé sur UNIX, il est possible de créer un processus grâce à la fonction conforme POSIX.1 :

Le type pid_t (déclaré dans sys/types.h) représente l’identificateur d’un processus (appelé PID pour Process IDentifier). En l’occurrence, la fonction renvoie trois valeurs, suivant ce qui s’est passé lors de l’exécution de cet appel-système :

• -1 en cas d’erreur, et errno est positionnée pour contenir le code de l’erreur (à savoir EAGAIN ou ENOMEM) ;
• 0 si on est dans le processus père ;
• une autre valeur, positive, indiquant le PID du processus créé (appelé processus fils).

Premier exemple pratique :

Le résultat peut varier selon l’ordre d’exécution des processus sur votre machine. Notez que la synchronisation des processus pourrait permettre une certaine unité, et ce sera l’objectif d’un des prochains articles !