Le langage C. Ecole Supérieure de Physique et de Chimie Industrielles de la Ville de Paris. Service Informatique Enseignement Année scolaire 2013/2014

Transcription

1 Ecole Supérieure de Physique et de Chimie Industrielles de la Ville de Paris Service Informatique Enseignement Année scolaire 2013/2014 Le langage C Didier Cassereau Téléphone : didier.cassereau@espci.fr

2

3 Chapter 1 La gestion de la mémoire Les ordinateurs actuels fonctionnent tous suivant une logique binaire ; ainsi la plus petite quantité d information que peut manipuler l ordinateur, le bit (binary digit), correspond à une logique à deux états (1 et 0, ou encore vrai et faux). Ces deux états logiques correspondent en pratique à deux états électriques différents (tensions électriques de 0 et ±V). Une logique à deux états étant très insuffisante pour coder de l information, on utilise des regroupements de 8 bits, autrement appelés octets (bytes en anglais). Un octet constitué de 8 bits permet donc d obtenir une logique à 256 états (2 8 ). Les langages de programmation permettent d utiliser des données stockées sur un nombre entier d octets consécutifs ; les manipulations sur les bits se font à partir d opérateurs spécifiques à chaque langage. On peut donner différentes représentations des 256 états possibles pour un octet : représentation décimale : valeurs comprises entre 0 et 255, ou encore entre -128 et +127, représentation binaire (codage en base 2) : valeurs comprises entre et , représentation hexadécimale (codage en base 16) : valeurs comprises entre 00 et FF, représentation "caractère" ou ASCII. On utilise également parfois un codage en base 8 (octal). La table ci-dessous donne les équivalents décimal, binaire, octal et hexadécimal des nombres entre 0 et 15. Décimal Binaire Octal Hexadécimal (base 10) (base 2) (base 8) (base 16) A B C D E F Toutes ces représentations sont parfaitement équivalentes et correspondent au même objet en mémoire. Pour la représentation "caractère", on utilise une table de conversion permettant de définir une correspondance bilatérale entre les 256 états logiques possibles et un ensemble de caractères imprimables ou 3

4 Chapitre 1 : La gestion de la mémoire non. Cette table de conversion définit ce que l on appelle la table des codes ASCII (American Standard Code for Information Interchange), elle permet en particulier d assurer que des ordinateurs différents utilisent les mêmes codes et sont capables de se comprendre. La table ASCII se décompose en réalité en deux parties : les codes ASCII standards, correspondant en représentation décimale à des codes entre 0 et 127 : cette table est universelle, quelque soit l ordinateur, le système d exploitation, le pays et la langue de fonctionnement ; elle comporte certains caractères non imprimables (codes de contrôles standards) ; elle définit également les 26 lettres minuscules, les 26 lettres majuscules, les chiffres de 0 à 9, les caractères de ponctuation,... ainsi le caractère A correspond au code décimal 65, le caractère 2 au code 50,... les codes ASCII étendus, correspondant en représentation décimale à des codes entre 128 et 255 : cette table n est pas universelle et peut dépendre de l ordinateur, du système d exploitation, du pays et de la langue de fonctionnement ; à titre d exemple, les caractères avec accents sont utilisés par la langue française mais non par la langue anglaise ; ces caractères sont donc utiles pour un ordinateur fonctionnant en français, mais ne sont d aucun intérêt aux Etats-Unis ; ainsi cette table de codes ASCII étendus permet de tenir compte de spécificités de certaines langues. La mémoire totale disponible d un ordinateur se compte en Ko (1 Ko = octets), en Mo (1 Mo = octets), voire même aujourd hui en Go (1 Go = octets). La taille des disques durs se compte maintenant au minimum en Go. Un objet quelconque stocké en mémoire est identifié par son adresse, cette adresse permet de situer l objet dans la mémoire totale de l ordinateur sans ambiguïté. Les anciens systèmes de type MS-DOS utilisaient une segmentation de la mémoire, c est-à-dire qu une adresse en mémoire était en fait constituée de deux informations indépendantes, le segment et l offset. Le principe de la segmentation consiste à "découper" (ce découpage n est que logiciel, il ne correspond à aucune réalité physique au niveau de l électronique de l ordinateur) la mémoire totale en groupes (ou segments) de 64 Ko ( octets). La partie segment d une adresse mémoire permet ainsi d identifier le numéro du segment à l intérieur duquel l objet est stocké. Quant à la partie offset, elle permet d identifier la position de l objet en mémoire à l intérieur du segment. Cette organisation de la mémoire est illustrée par la figure ci-dessous. Un tel découpage de la mémoire n est pas sans conséquences au niveau de la programmation : il n est pas possible de définir un objet en mémoire stocké à cheval sur plusieurs segments (à part dans le cadre d environnements de programmation spécifiques) ; en particulier cela rend impossible la manipulation d objets dont la taille excède octets, un programme peut utiliser deux modes d adressage, court (attribut near assembleur, le segment de stockage est alors supposé connu par ailleurs, et seul l offset est nécessaire pour localiser l objet en mémoire) ou long (attribut far assembleur, segment et offset sont alors nécessaires pour localiser l objet en mémoire). 4

5 Chapitre 1 : La gestion de la mémoire Segment et offset sont stockés chacun sur 16 bits, ce qui donne un adressage sur 16 bits ou 32 bits suivant que l on utilise l adressage court ou long. L existence de ces deux modes d adressage complique souvent la tâche du programmeur dans l élaboration des applications. Dans le monde des PC, les systèmes fonctionnant sur ce principe étaient MS-DOS et Windows 95/98/Me (ou versions antérieures), qui sont aujourd hui principalement des systèmes obsolètes. Les systèmes d exploitation actuels tels que Windows NT/XP/Vista, ou encore les systèmes Unix, utilisent majoritairement un adressage sur 32 bits, sans segmentation. L un des intérêts de cette gestion de la mémoire est de mettre à disposition du programmeur un seul et unique mode d adressage. Un adressage sur 32 bits permet de gérer jusqu à octets (2 32 ). Certains systèmes d exploitation utilisent aujourd hui des adressages sur 64 bits, en particulier avec les micro-processeurs 64 bits. 5

6

7 Chapter 2 La mémoire vue par un programme 2.1 Introduction Un programme qui s exécute sur un ordinateur utilise différentes zones de la mémoire bien identifiées, parmi lesquelles : la zone de code (code en anglais) : cette zone contient les instructions binaires du programme qui s exécute ; cette zone de la mémoire est figée au démarrage et n est pas directement utilisable par le programme lui-même, la zone des données (data en anglais) : cette zone correspond à un espace mémoire créé au démarrage du programme ; elle est utilisée pour stocker en mémoire tous les objets manipulés par le programme au cours de son exécution ; la taille de cette zone mémoire est figée dès le démarrage du programme et dépend du nombre et de la nature des objets manipulés par le programme, la pile (stack en anglais) : cette zone de la mémoire est également créée au lancement du programme, avec une taille fixée à l avance ; cette zone est utilisée comme espace temporaire de travail ; les fonctions assurées par la pile sont détaillées ci-dessous, le tas (heap en anglais) : cet espace mémoire est à la disposition du programmeur à tout moment ; on peut l occuper de façon temporaire ou permanente pour y stocker des données, elle n est généralement pas limitée en taille, hormis certaines limites imposées par le système d exploitation ; nous verrons ultérieurement comment utiliser cet espace mémoire à partir des fonctions standards du langage C (allocation dynamique de mémoire). La pile est un espace temporaire de travail utilisé par le programme (mais non directement par le programmeur) suivant un processus LIFO (Last In First Out) ; autrement dit, les objets en mémoire dans la pile sont dépilés (ou supprimés car désormais inutiles) dans l ordre inverse d empilement. Cette pile a plusieurs fonctions que nous allons présenter. 2.2 L exécution d un sous-programme Tous les langages de programmation évolués mettent à la disposition du programmeur les notions de fonctions et sous-programmes. Les fonctions sont importantes en programmation car, utilisées de façon adéquate, elles permettent de structurer le programme de façon claire. Du point de vue du code binaire du programme, la partie exécutable d une fonction est stockée quelque part à l intérieur du code global. Les différentes étapes sont illustrées par la figure ci-dessous : l instruction en cours d exécution est un appel de fonction : il faut alors déplacer le pointeur d exécution (qui identifie l instruction en cours de traitement) et le positionner au début de la fonction appelée, ensuite on exécute la fonction jusqu à ce que l on rencontre l instruction de fin de fonction, 7

8 Chapitre 2 : La mémoire vue par un programme ensuite il faut déplacer à nouveau le pointeur d exécution et le positionner sur l instruction qui suit l appel de la fonction afin que l exécution du programme se poursuive de façon logique. Il est clair qu un mécanisme de ce type ne peut fonctionner que si le programme se souvient, d une façon ou d une autre, vers quelle instruction de la zone de code il doit retourner après exécution de la fonction. Il s agit là du premier rôle de la pile puisque c est dans cette zone de la mémoire que cette information est stockée temporairement, durant tout le temps d exécution de la fonction. Ainsi, la séquence des opérations mises en oeuvre lors d un appel à une fonction est la suivante : empilement de l adresse de retour, déplacement du pointeur d exécution vers le début de la fonction, exécution de la fonction, en fin de fonction, dépilement de l adresse de retour et déplacement du pointeur d exécution vers cette adresse, poursuite de l exécution du programme. 2.3 Le passage des paramètres à un sous-programme ou une fonction Classiquement, il est possible de transmettre un ou plusieurs paramètres à un sous-programme ou une fonction ; on peut également choisir de ne passer aucun paramètre. C est la syntaxe de déclaration du sous-programme ou de la fonction qui conditionnera le nombre de paramètres qu il (elle) recevra. L intérêt de ce passage de paramètres est de permettre d utiliser le sous-programme ou la fonction avec des données fluctuantes non figées au moment de l écriture du programme. Les paramètres transmis à une fonction n ont pas d existence réelle en dehors du contexte de la fonction elle-même ; ils n existent que le temps d exécution de la fonction. On peut donner l exemple de la fonction sin à laquelle on transmet un paramètre de type réel et qui renvoie le sinus du nombre réel transmis à la fonction. Ce mécanisme de transmission de paramètres à un sous-programme ou à une fonction se fait par l intermédiaire de la pile. Avant de déplacer le pointeur d exécution vers la première instruction de la fonction à exécuter, le programme empile le ou les paramètre(s) à transmettre à la fonction ; la première chose que fait ensuite la fonction consiste à dépiler le ou les paramètre(s) en question afin de récupérer les données de façon correcte. Ce mécanisme d empilement et de dépilement ne se passe bien que si l on est sûr qu il y a parfaite cohérence entre le nombre de paramètres empilés et le nombre de paramètres déclarés pour la fonction. De même il est impératif que le type de chacun des paramètres (entier, réel,...) soit cohérent entre la 8

9 Chapitre 2 : La mémoire vue par un programme fonction et le programme qui utilise la fonction. Dans le cas contraire, le dépilement ne se fait pas de la même façon que l empilement, et la fonction ne peut pas interpréter les données empilées de la même façon que le programme appelant. Ce type de situation est souvent incompatible avec un bon fonctionnement du programme. Un mauvais exemple consiste par exemple à faire appel à la fonction sin en lui transmettant un paramètre entier, ou encore deux paramètres réels! alors que la fonction est conçue pour ne recevoir qu un seul paramètre réel. Il existe deux modes de passage des paramètres à une fonction : le passage par valeur, le passage par adresse Le passage par valeur Lors d un passage de paramètre par valeur, c est l ensemble des zones mémoire occupées par le paramètre qui sont dupliquées vers la pile ; il en résulte que le paramètre apparaît en double dans la mémoire, pendant tout le temps d exécution de la fonction. D autre part, la fonction ne connaît que la version dupliquée du paramètre et ignore tout de l original. Ce mode de passage est illustré par la figure ci-dessous ; les conséquences sont les suivantes : le paramètre devant être dupliqué dans la pile, il faut tenir compte du temps effectif de duplication en cours d exécution ; ce temps sera d autant plus long que le paramètre occupera plus de place en mémoire, si le paramètre occupe une place trop importante en mémoire, la présence de plusieurs occurrences de ce paramètre dans la pile peut poser problème (débordement de la pile par exemple), la fonction ne connaît que la version dupliquée du paramètre ; si la fonction modifie le paramètre en question, les modifications n affectent que la version dupliquée et non l original ; il en résulte que les modifications sont effectives tant que la fonction s exécute, mais elles sont définitivement perdues dès sortie de la fonction et retour au programme appelant Le passage par adresse Le passage par adresse d un paramètre est le passage par valeur de l adresse du paramètre. Ce mode de passage est illustré par la figure ci-dessous ; les conséquences sont les suivantes : c est l adresse du paramètre et non le paramètre lui-même qui est dupliqué dans la pile ; par conséquent la duplication ne se fait que sur les 4 octets (dans le cas d un système 32 bits) de l adresse et non plus sur les N octets occupés par le paramètre ; il en résulte généralement un gain de temps en cours d exécution par rapport au passage par valeur, 9

10 Chapitre 2 : La mémoire vue par un programme pour la même raison, les risques d encombrement de la pile sont généralement moindres en utilisant le passage par adresse plutôt que le passage par valeur, il n existe qu un seul original du paramètre puisque seule son adresse est dupliquée dans la pile ; si la fonction modifie le paramètre en question, les modifications affectent donc l original ; il en résulte que les modifications sont effectives tant que la fonction s exécute, mais restent également acquises dès sortie de la fonction et retour au programme appelant. 2.4 Le stockage des variables locales Une fonction ou un sous-programme peut définir des variables locales ; ces variables n existent que lorsque la fonction est en cours d exécution. Elles sont créées dans la pile lorsque l exécution de la fonction démarre, et sont supprimées à la sortie de la fonction lors du retour au programme appelant. Il en résulte deux conséquences importantes : l état de ces variables locales n est pas utilisable en dehors du contexte de la fonction elle-même ; il est absolument exclu que le programme fasse référence à ces variables, d une quelque façon que ce soit, on ne peut pas réutiliser l état de ces variables tel que l a laissé une exécution précédente de la même fonction ; en effet, les zones mémoire peuvent parfaitement avoir été utilisées entre temps pour toute autre chose! d autre part, le mécanisme d occupation et de libération de la pile étant totalement dynamique, on n est jamais sûr que les variables locales seront empilées au même endroit en mémoire entre deux exécutions consécutives de la même fonction ; de façon générale, le programmeur ne contrôle absolument pas l usage qui est fait de la pile par son programme. 2.5 Les calculs intermédiaires Certaines expressions arithmétiques par exemple ne peuvent pas être évaluées en une seule fois par le programme, en particulier si l expression fait apparaître plusieurs opérateurs. Ainsi, une expression du type a + b + c + 2 * d + log ( e / f) sera évaluée de la façon suivante : temp1 = a + b temp2 = temp1 + c 10

11 Chapitre 2 : La mémoire vue par un programme temp3 = 2 * d temp4 = temp2 + temp3 temp5 = e / f temp6 = log(temp5) résultat = temp4 + temp6 Le programme a donc besoin de zones de stockages temporaires pour garder en mémoire les résultats intermédiaires au fur et à mesure qu il traite l expression à évaluer. Ces zones temporaires utilisent la pile. 2.6 Le débordement de la pile On a vu que la pile est en fait une zone de la mémoire de l ordinateur qui est occupée ou libérée de façon complètement dynamique en fonction des besoins du programme en cours d exécution. Comme la pile a une taille finie au départ, il peut arriver un problème de débordement de la pile (stack overflow en anglais) ; il s agit là d une erreur grave qui entraîne une interruption immédiate du programme, quel que soit l état d avancement de l exécution. En cas de débordement de la pile, on peut rechercher parmi les différentes causes possibles : l exécution d un sous-programme ou d une fonction : on a vu que chaque appel de sous-programme ou fonction génère un empilement de l adresse de retour ; on peut donc imaginer qu un nombre excessif d appels de fonctions pourrait générer un débordement de la pile ; en pratique c est rarement le cas car on n empile que 4 octets! sauf dans le cas d appels récursifs (la fonction s appelle ellemême, semblable à la récurrence mathématique) non contrôlés, le passage des paramètres à un sous-programme ou une fonction : à nouveau ce mécanisme utilise la pile et peut donc générer un débordement de la pile, en particulier si les paramètres empilés occupent une grande place en mémoire et sont transmis par valeur ; en outre, toute fonction pouvant appeler une autre fonction et lui transmettre un paramètre qu elle a reçu d une fonction appelante, on peut parfaitement imaginer qu un paramètre donné se trouve dupliqué 2, 3, 4... fois en mémoire, ce qui peut rapidement être ingérable si le paramètre occupe trop de place en mémoire ; dans ce cas, il est préférable d envisager un passage par adresse, le stockage des variables locales : à nouveau, un nombre excessif de variables locales peut générer un débordement de pile ; dans ce cas, on peut par exemple envisager de stocker les variables dans la zone de données plutôt que dans la pile, ou encore dans la zone de mémoire de tas ; on verra ultérieurement comment forcer le stockage de données dans ces zones particulières de la mémoire, les calculs intermédiaires : ces calculs nécessitent de très petites quantités de mémoire à l intérieur de la pile, il est donc très rare que ce genre de calcul génère un débordement de la pile. Parmi ces différentes causes possibles, les plus probables sont : appels récursifs incontrôlés, trop de passages par valeur de paramètres occupant trop de place en mémoire, trop de variables locales déclarées dans les diverses fonctions. Une autre solution peut également consister à augmenter la taille de la pile par défaut au lancement du programme ; il s agit là d une option de compilation, propre au compilateur utilisé. Il faut donc se référer à la documentation du compilateur. 11

12 Chapitre 2 : La mémoire vue par un programme 2.7 L intégrité de la pile Il est important de noter que toute la gestion de la pile est assurée par le programme lui-même ; ce n est en particulier pas au programmeur de s occuper de ces opérations. On pourrait en conclure un peu rapidement que les problèmes d intégrité de la pile ne sont pas du ressort du programmeur. En réalité, un programme mal écrit peut avoir des conséquences imprévues sur cette intégrité de la pile, entraînant par la même occasion un dysfonctionnement majeur du programme. Un débordement de tableau au cours de l exécution d une fonction a souvent ce genre de conséquences, provoquant un arrêt immédiat du programme. Pour la petite histoire, il est de notoriété publique qu il circule actuellement une quantité colossale de virus et vers sur Internet ; la très grande majorité de ces virus visent les systèmes Windows et leur grande vulnérabilité. Un des mécanismes souvent utilisé consiste à envoyer à l application visée des données trafiquées produisant un débordement de mémoire ; parmi toutes ces données se trouve le code exécutable permettant l installation du virus sur l ordinateur attaqué. Le débordement de mémoire est alors fait de telle sorte que le dépilement de l adresse de retour après exécution de la fonction en cours renvoie vers le code du virus, et non vers le code de l application elle-même. La première conséquence est que le virus peut s installer sur l ordinateur ; la seconde conséquence, souvent immédiate, est l interruption de l application qui a subi l attaque. Ce mécanisme est très fréquent, c est la raison pour laquelle il est essentiel de veiller en permanence à éviter toute forme de débordement de tableau. 12

13 Chapter 3 L écriture d un programme 3.1 Le langage de programmation Le programme informatique est constitué d une série d instructions écrites dans le langage de l ordinateur, et permettant d effectuer certaines tâches ou calculs précis. Les instructions doivent être écrites dans un langage compréhensible par l ordinateur, c est-à-dire que l on doit indiquer à tout moment toutes les séquences à exécuter par le microprocesseur. Ceci est particulièrement long et rébarbatif ; d autre part c est généralement plutôt complexe et réservé aux experts. Le programmeur a alors recours à un langage de programmation. Le langage de programmation est relativement proche du langage humain, il est souvent à base de langue anglaise. Comme tout langage, il comporte diverses contraintes, en particulier au niveau de la grammaire et du vocabulaire à utiliser. A la différence du langage humain, le langage de programmation est généralement très intransigeant par rapport aux règles qui le régissent, supportant assez mal les originalités grammaticales ou l utilisation de synonymes par exemple. Néanmoins, ces contraintes sont relativement mineures par rapport à ce qu apporte le langage de programmation, à savoir une interface simple et claire entre le programmeur et l ordinateur. Avant l exécution du programme, il est alors nécessaire de traduire ce qui a été écrit pour le rendre compréhensible et exploitable par l ordinateur. Deux cas de figures sont possibles : la traduction se fait ligne par ligne, au fur et à mesure de l exécution du programme : on parle alors de langage interprété, la traduction étant gérée par un interpréteur ; l avantage de cette méthode est de rendre l exécution (et les tests) très interactive avec l écriture du programme ; l inconvénient majeur est qu en phase d exécution, une partie non négligeable du temps est consacré à des tâches de traduction sans rapport direct avec ce que doit faire le programme, la traduction se fait globalement pour l ensemble du programme et l exécution ne se fait qu après : on parle alors de langage compilé, la traduction étant gérée par un compilateur ; l avantage est que toutes les opérations de traduction sont faites une fois, l exécution pouvant ensuite se faire avec une vitesse optimale. A ce jour, la quasi totalité des langages de programmation sont des langages compilés ; ils sont très largement meilleurs que leurs homologues interprétés, en particulier au niveau du temps d exécution. 3.2 Ecrire un "bon" programme Ecrire un "bon" programme est souvent une tâche assez ardue, d autant plus qu il est difficile de définir précisément ce que l on entend par "bon". On peut néanmoins essayer de préciser certaines règles, qui sont souvent des règles de bon sens, et que tout programmeur a intérêt à respecter : une réflexion minimale sur ce que doit faire le programme et la façon dont il sera organisé, est largement souhaitable ; on voit trop de gens qui se lancent "tête baissée" dans la programmation avant même d avoir lu complètement un énoncé... le programme doit être commenté, pour expliquer en quelques mots ce qu il fait, et comment il procède ; l absence totale de commentaires est rapidement préjudiciable et rend la lecture du programme difficile ; à l inverse un excès de commentaires peut également nuire à une bonne lisibilité ; à chacun de trouver le meilleur compromis, 13

14 Chapitre 3 : L écriture d un programme le programme doit être clairement écrit et présenté ; les langages de programmation modernes offrent au programmeur une très grande souplesse dans la présentation du code source, il est donc souhaitable d en profiter pour présenter le programme de façon aussi claire que possible, en utilisant des règles souvent très simples telles que l insertion de lignes blanches, l indentation de blocs d instructions,... il faut éviter l écriture de fonctions trop longues ; cela devient très rapidement lourd et indigeste, voire illisible ; il ne faut pas perdre de vue que tout programme devra un jour être corrigé ou modifié ; écrire des fonctions claires et simples permet de se donner un maximum de chances de trouver les erreurs lorsqu elles ne manqueront pas d apparaître, il est vivement conseillé de structurer le programme et de le découper en petites fonctions, effectuant des tâches précises dans des contextes précis ; chaque fonction peut ensuite être testée indépendamment, avant d être ajoutée à l ensemble du programme ; il est de loin préférable d écrire un programme constitué d une multitude de petites fonctions plutôt qu une fonction unique répétant de nombreuses fois les mêmes séquences de code. Une fois ces quelques règles énoncées et respectées, on peut donner quelques autres critères qui permettent de qualifier un "bon" programme : il doit faire ce qu on lui demande, et obtenir les résultats corrects de façon répétitive! le programme doit fournir les mêmes résultats, indépendamment du jour et de l heure de son lancement, indépendamment de qui le lance! l exécution du programme doit pouvoir se dérouler normalement sans incidents, du début jusqu à la fin, il doit se comporter de façon stable et ne pas présenter de dysfonctionnements lorsque l on fait varier l un des paramètres de quelques %, il doit être souple et paramétrable ; un programme calculant la chute d un objet sur terre doit pouvoir refaire le même calcul sur la lune sans pour autant imposer de tout réécrire, il doit être évolutif : un programme informatique reste rarement figé, il faut souvent faire des modifications pour ajouter de nouvelles fonctions ; le "bon" programme est un programme que l on pourra assez facilement faire évoluer, sans faire apparaître des dizaines d erreurs grossières à chaque nouvelle instruction ajoutée au code initial ; seul un programme bien structuré et commenté permettra d assurer cette condition, il doit être rapide ; inutile de passer une heure à faire un calcul que l on pourrait tout aussi bien faire en 3 secondes, à condition de réécrire un peu la structure du programme ; entre un programme bien conçu et un programme mal optimisé, on peut très facilement obtenir des facteurs considérables en temps de calcul, pour des résultats finaux identiques. On pourrait certainement trouver de multiples autres critères pour qualifier un "bon" programme, mais il n est pas question d en dresser ici une liste exhaustive. Il est important de comprendre que souvent ces critères relèvent du bon sens. Voici quelques petits exemples de "mauvais" programmes qui coûtent très cher : tous les programmes qui ont pu présenter de graves dysfonctionnements le 1er janvier 2000 à 0h00! des investissements colossaux ont été faits partout dans le monde afin d assurer que les ordinateurs puissent franchir cette étape correctement, le code de gestion de la trajectoire des missiles anti-missiles américains Patriot à l occasion de la première guerre de Golfe... le code de contrôle de la trajectoire de la première fusée Ariane V qui a fini dans les marécages... et tous les programmes et utilitaires de gestion des systèmes d exploitation, mal écrits et mal pensés, qui sont aujourd hui le paradis des pirates informatiques! le problème du mardi 19/01/2038 à 03:14:07... et sûrement bien d autres... 14

15 Chapter 4 Le langage C 4.1 Introduction Le langage C a été développé par B. Kernighan et D. Ritchie. L une des caractéristiques essentielles de ce langage est d être facilement portable d une machine à l autre, sous réserve d écrire le code source de façon adéquate. Il est ainsi possible, à partir des mêmes fichiers sources écrits en C, de générer les codes exécutables sur tout type de machine. Cette caractéristique du C est certainement à l origine de la popularité croissante de ce langage. D autre part, ce langage est à la base des systèmes Unix. A l origine, le langage C présentait un inconvénient majeur par rapport au langage Pascal. En effet, les compilateurs Pascal sont très stricts quant au respect des règles syntaxiques. Ainsi, il n est pas possible d utiliser une variable ou une fonction non déclarée, ni une fonction avec une syntaxe différente de celle utilisée lors de la déclaration de la fonction en question. Ces règles rigoureuses sont très utiles dans l apprentissage de la programmation puisqu elles créent un cadre de travail rigide, ce qui permet d éviter un grand nombre d erreurs grossières. Une telle rigueur n existe pas dans le langage C d origine, ce qui nécessite une très grande prudence de la part du programmeur. Avec le succès et le développement croissant de ce langage est apparue la nécessité de standardiser les choses. De gros efforts ont été faits dans ce sens par l American National Standards Institute et l International Standards Organization, conduisant ainsi à la norme ANSI C (ou autrement appelée ISO C). C est dans le cadre de cette norme que nous nous placerons dans ce document. Depuis quelques années, le langage C a encore considérablement évolué avec l apparition du C++, version orientée objets du langage C d origine. 4.2 Méthodes de travail Le langage C est un langage compilé. Par conséquent, le travail se fait en trois étapes successives : écriture du programme avec n importe quel éditeur de texte (si l on utilise un environnement de développement intégré, ce dernier dispose généralement d un éditeur de texte ; dans le cas contraire, n importe quel éditeur peut faire l affaire), compilation du programme et édition des liens, exécution du programme et tests. A titre de rappel, l édition des liens consiste à ajouter au programme un ensemble de librairies permettant ainsi de générer un code exécutable et indépendant. Les librairies classiques sont les librairies système, mathématique, graphique, La compilation d un programme C Noter que tout ce qui suit est valable pour d autres langages de programmation ; la mise en oeuvre est illustrée avec le langage C, mais la logique de fonctionnement serait strictement identique en Fortran, Pascal... 15

16 La compilation d un programme consiste à analyser le contenu du programme source, à en vérifier la syntaxe (grammaire et vocabulaire), et à générer un fichier dit objet, résultat de la traduction du programme en langage machine. Ainsi, la compilation d un programme "essai.c" entraîne la création d un fichier objet "essai.o" (cette convention d appellation du fichier objet est la plus courante sur tous les systèmes Unix ; certains compilateurs dans l environnement Windows utilisent la convention "essai.obj", mais le principe reste le même). Le fichier objet, résultat de la compilation, n est pas exécutable ; pour cela, il faut également procéder à l édition des liens qui va permettre d ajouter au programme un certain nombre de fonctions et outils standards apportés par le langage. Le compilateur fournit un rapport des éventuelles erreurs qu il a détectées au cours de l analyse du programme. On distingue deux types de messages : les messages d erreur proprement dits, les messages de warning. Les messages d erreur Tout écart par rapport aux règles grammaticales et syntaxiques du langage C conduit à un message d erreur ; ce message est généralement accompagné du numéro de ligne où l erreur a été détectée, ainsi que d un texte explicatif bref indiquant la nature de l erreur. Le langage C, et a fortiori le langage C++, est très rigoureux dans la procédure de compilation, ce qui garantit un bon niveau de cohérence du programme lorsque toutes les erreurs sont corrigées. Attention, l absence d erreurs à la compilation ne garantit nullement que l exécution du programme se passera bien! Une erreur doit impérativement être corrigée. La présence d une erreur, quelle qu elle soit, empêche l édition des liens ultérieure, et donc les tests du programme. Les messages de warning Ces messages ne sont pas des erreurs dans la mesure où le compilateur n a pas détecté d entorse aux règles grammaticales du langage. En revanche, ces messages sont susceptibles d apparaître lorsque le compilateur rencontre une situation qui lui semble "suspecte". Ces messages n empêchent ni la création du fichier objet, ni l édition des liens, ni l exécution du programme. Face à de tels messages, on peut envisager trois attitudes possibles : les ignorer puisque ce ne sont pas des erreurs, ignorer les messages sans importance et corriger les messages pouvant être plus graves, corriger tous les messages de façon systématique. La première attitude n est en aucun cas recevable car il existe certains messages de warning qui nécessitent impérativement correction. La deuxième attitude est acceptable, mais difficile à mettre en oeuvre. En effet, elle suppose que le programmeur sache faire la distinction entre les messages sans importance et les messages graves ; d autre part, un message grave peut parfaitement passer inaperçu parmi une multitude de messages sans importance. La troisième et dernière attitude est vivement conseillée, en particulier pour les programmeurs débutants, d autant que bien souvent la correction est très simple et rapide à mettre en oeuvre. On peut généralement configurer le compilateur afin qu il considère les warnings au même titre que les erreurs, et ainsi forcer le programmeur à effectuer toutes les corrections nécessaires. Par ailleurs, il existe souvent des options permettant d augmenter ou de diminuer la susceptibilité du compilateur dans son mécanisme de détection des situations suspectes. De manière générale, il est vivement préférable de n accepter aucune tolérance. 16

17 4.2.2 L édition des liens Les différentes fonctions d un programme ne sont pas nécessairement toutes incluses dans un même fichier source. Dans ce cas, il est indispensable de lier les différents fichiers ".o" issus de la compilation des différents fichiers source afin de construire un fichier exécutable correct. D autre part, il est indispensable d ajouter aux fonctions propres du programmeur un certain nombre de fonctions issues des librairies standards du langage C, parmi lesquelles on trouve les librairies système, mathématique, graphique,... L édition des liens consiste donc à rassembler tous ces éléments pour pouvoir finalement créer un programme exécutable complet capable de se lancer normalement. Cette seconde étape après compilation est indispensable puisque c est elle et elle seule qui permet d obtenir le programme exécutable final. Sur les systèmes d exploitation de type MS-DOS et Windows, le programme exécutable aura l extension ".exe". Une telle extension du nom du fichier exécutable n est absolument pas imposée par les systèmes Unix. Les deux types d erreurs les plus fréquentes que l on rencontre au cours de la phase d édition des liens sont les suivantes : fonction (ou plus généralement objet) non définie : le programme fait référence à une fonction pour laquelle l éditeur de liens n a pas trouvé le code exécutable, ni dans les librairies standards, ni dans les différents fichiers ".o" fournis par le programmeur ; cette erreur doit impérativement être corrigée pour réussir à créer le programme exécutable, fonction (ou plus généralement objet) définie plus d une fois : le programme fait référence à une fonction pour laquelle l éditeur de liens a trouvé plusieurs implémentations du code exécutable ; à nouveau cette erreur doit impérativement être corrigée, l éditeur de liens ne prenant pas l initiative de choisir une implémentation particulière au détriment des autres. Dans la plupart des cas, ces erreurs sont assez faciles à corriger L exécution du programme - premiers tests Une fois que les phases de compilation et d édition des liens sont terminées, le programme peut être exécuté et testé. C est là qu apparaissent les erreurs à corriger ultérieurement. On peut distinguer plusieurs cas : le programme semble bloqué, sans affichages particuliers : dans ce cas, il faut dans un premier temps penser que le programme attend peut-être simplement une valeur à saisir au clavier ; un autre cas de figure est que le programme est en train de calculer, ce qui peut aussi signifier que le programme est entré dans une boucle infinie par exemple ; c est alors au programmeur de modifier son programme afin d affiner le diagnostic et corriger les éventuelles erreurs, le programme semble fonctionner, mais fournit des résultats incorrects : dans ce cas, seul un examen approfondi des différentes étapes de calcul permettra de détecter une erreur ; il est souvent utile de tester un programme avec des données simples pour lesquelles le calcul "à la main" est possible ; cela permet ainsi de confronter, étape par étape, les résultats obtenus par les deux méthodes jusqu à observer une divergence, le programme s interrompt brutalement avec un message d erreur : dans ce genre de situation, le programme a rencontré une erreur grave qui l empêche de poursuivre son exécution ; le système d exploitation prend alors l initiative d interrompre l exécution avec un message d erreur adéquat ; le programmeur doit alors d une part comprendre la nature de l erreur, d autre part localiser la cause de l erreur et effectuer les corrections qui s imposent. 17

18 Les messages d erreurs les plus courants rencontrés avec le compilateur cc sous Unix sont segmentation fault, memory fault ou bus error : ces erreurs correspondent à des erreurs de manipulation de la mémoire ; ces erreurs sont graves et doivent évidemment être corrigées. De façon générale, l exécution et les premiers tests constituent une phase assez délicate dans la mesure où il faut localiser et corriger les erreurs. Comprendre l origine d une erreur et la localiser dans l ensemble du programme est probablement la partie la plus difficile. D autre part, il arrive parfois qu une erreur se produise à l exécution, conséquence d une erreur faite ailleurs dans le programme. Dans ce cas, la recherche de la cause première du problème est d autant plus délicate. Les environnements de développements modernes mettent à la disposition du programmeur un mode d exécution dit "pas à pas", permettant de contrôler toute action du programme, ligne par ligne. Cela permet de vérifier la cohérence des données manipulées par le programme en temps réel, ce qui constitue souvent un outil très puissant et efficace dans la recherche d erreurs. Il est souvent utile d apprendre à utiliser ce genre d environnement Exemples avec le compilateur cc Le compilateur cc est celui que l on trouvera en standard sur tous les systèmes Unix ; dans certains cas, on disposera également d une variante gcc, dont le mécanisme de fonctionnement reste similaire. Les syntaxes des commandes suivantes correspondent à ce compilateur particulier ; si vous êtes conduit à utiliser un compilateur différent, vous devez vous référer à la documentation correspondante. Nous supposons avoir écrit un programme dans un fichier nommé essai.c ; ce fichier est écrit avec un éditeur de texte quelconque, tel que par exemple vi ou nedit. La commande de compilation du fichier essai.c pour créer le fichier objet essai.o s écrit par exemple de la manière suivante : cc -c essai. c - Wall - Wextra - Werror -O - pedantic - Wshadow Les différents éléments composant cette commande sont les suivants : cc : on invoque ici la commande unix cc (comme C Compiler), -c : cette option permet de spécifier que l on ne fait que la compilation, sans enchaîner directement avec l édition des liens (qui est faite ultérieurement), -Wall : cette option permet de configurer le compilateur avec une tolérance minimale vis à vis des instructions potentiellement suspectes ; cette option est certes un peu contraignante, mais elle permet d éviter de multiples erreurs par la suite, -Wextra : cette option complète l option précédente de manière parfois utile, -Werror : cette option permet de spécifier au compilateur que les instructions suspectes doivent être traitées comme des erreurs (ce qui interdit la création du fichier objet, et donc empêche l édition des liens et l exécution ; cela force le programmeur à corriger systématiquement toutes les instructions suspectes), -O : cette option correspond à une étape d optimisation du programme ; elle est ici intéressante dans la mesure où certaines situations suspectes ne sont détectées que lors de la phase d optimisation (comme par exemple l utilisation d une variable non initialisée), -pedantic : cette option permet de désactiver certaines possibilités offertes par les compilateurs récents, mais qui peuvent s avérer dangereuses si elles sont utilisées sans précaution, -Wshadow : cette option est principalement utile en langage C++, elle permet de détecter les risques de confusion entre un paramètre transmis à une fonction et une autre variable connue dans le contexte et qui aurait le même nom ; cette situation peut rapidement apparaître lorsque l on implémente une méthode (fonction) d une classe C++, et il est très important de pouvoi diagnostiquer ce genre de problème au moment de la compilation. 18

19 Dans cet exemple, l ordre dans lequel les différents éléments constituant la commande est sans importance. En revanche, le compilateur fait la distinction entre les majuscules et les minuscules, aussi bien pour ce qui est des noms des fichiers que pour les options transmises à la commande de compilation. La seconde commande pour l édition des liens s écrit sous la forme suivante : cc -o essai essai. o - lm De même que pour la commande précédente, l ordre des différents éléments est sans importance, hormis l option -o qui ne peut pas être dissociée du paramètre suivant essai ; cette option consiste simplement à nommer le fichier exécutable à créer à l issue de l édition des liens, le paramètre suivant essai correspondant au nom du fichier à utiliser. Si cette option n est pas spécifiée, le nom du programme exécutable créé par défaut est a.out. Le paramètre suivant, essai.o, correspond au nom du fichier objet qui a été créé lors de la phase de compilation. La dernière option précisée dans l exemple ci-dessus, -lm, permet d inclure la librairie mathématique standard dans la phase d édition des liens. Dans certains environnements de compilation, cette option peuv s avérer indispensable dès lors que le programme manipule une des fonctions mathématiques de base, telles que sin, cos, exp,... Dans certains cas, d autres paramètres peuvent être nécessaires dans cette commande d édition des liens, en particulier si vous devez inclure des librairies ou objets supplémentaires pour constituer le programme exécutable. Lorsque vous modifiez votre programme, vous manipulez le fichier essai.c ; il est alors impératif de lancer ces deux commandes (compilation, puis édition des liens) dans cet ordre précis, afin que le programme exécutable prenne en compte vos dernières modifications. Dans le cas contraire, les modifications du programme source sont sans conséquences sur l exécution et les tests qui suivent. Les systèmes unix disposent d un outil standard très performant permettant d automatiser ces procédures de compilation, et d éviter toute erreur de cette nature. Cet outil correspond à la commande make, qui utilise un fichier de règle (dont le nom est par défaut makefile ou Makefile). Voir à la fin de ce document pour un descriptif plus détaillé de cet outil. 4.3 Règles syntaxiques de base Comme tout langage évolué, le langage C définit un ensemble de règles syntaxiques que le programmeur doit respecter scrupuleusement. Dans le cas contraire, la compilation du programme conduit à un message d erreur approprié. Le format d édition est totalement libre, comme en Pascal. Ainsi, il est possible d écrire plusieurs instructions sur une même ligne, ou encore de séparer les instructions par un nombre variable d espaces,... Cette liberté est importante car elle permet au programmeur de présenter son code source de façon la plus lisible possible. De même qu en Pascal, toute instruction doit être terminée par ";", et toute variable doit impérativement être déclarée avant d être utilisée. En revanche, il n est pas indispensable de déclarer à l avance les fonctions que l on utilise, mais cette règle est toutefois vivement conseillée (la convention C++ impose cette règle pour les fonctions comme pour les variables). Une fonction non déclarée avant utilisation est considérée comme renvoyant par défaut une valeur entière. Les commentaires sont autorisés et conseillés afin d améliorer la lisibilité des programmes. Une zone de commentaires s ouvre avec "/*" et se ferme avec "*/", respectivement équivalents aux "(*" et "*)" du Pascal. Tout texte situé entre "/*" et "*/" est ignoré par le compilateur. Il est en général déconseillé d imbriquer des zones de commentaires, certains compilateurs ne l acceptant pas. Contrairement au langage Pascal, le langage C fait la distinction entre les caractères majuscules et minuscules pour les identificateurs de variables, de fonctions, et pour toutes les instructions standards. Ainsi, il est tout à fait possible de déclarer et utiliser deux variables appelées "x" et "X", indépendantes l une de l autre. 19

20 4.4 Les types de données en langage C Le langage C met à la disposition du programmeur un certain nombre de types de données standards, auxquels peuvent s ajouter tous les types de données propres à chaque programmeur. Parmi les types de données standards, on distingue deux grandes classes : les types de données entières, les types de données réelles, ou encore en virgule flottante Les types de données entières Toutes les données entières sont codées de façon binaire (décomposition en base 2) ; c est la décomposition la plus naturelle puisqu elle correspond à la structure électronique de l ordinateur. Toute valeur entière peut être signée ou non ; une valeur non signée ne pourra prendre que des valeurs positives, 0 inclus ; une valeur signée pourra prendre des valeurs positives ou négatives. L information de signe est portée par l un des bits de stockage de la donnée, dit bit de signe ; ce bit est à 0 pour une valeur positive, à 1 pour une valeur négative. Attention, la valeur absolue d une quantité entière négative est codée en binaire, mais en complément à 2. Considérant une valeur entière stockée sur 2 octets, on peut regarder de près la décomposition binaire de cette valeur pour chacun des octets qui la constitue. Dans la table suivante, on indique les décompositions binaires et correspondances décimales de chacun des deux octets ; pour le deuxième octet, on a isolé le premier bit qui est le bit de signe. On donne également la formule de reconstruction qui permet de retrouver la valeur numérique correcte. Pour les valeurs négatives, on constate que c est le complément à 2 (hors bit de signe) qui permet de retrouver la valeur correcte. Valeur décimale 2ème octet 1er octet Formule de reconstruction (0) (17) 256* (108) (206) 256* (255) (231) complément à (bit de signe, 0) (24) -(256*0+24) (148) (87) complément à (bit de signe, 107) (168) -(256* )-1 Le langage C définit les données entières suivantes : Type de donnée Déclaration Valeur minimale Valeur maximale entier 8 bits signé char entier 8 bits non signé unsigned char entier 16 bits signé short entier 16 bits non signé unsigned short entier 32 bits signé long entier 32 bits non signé unsigned long Le mot clé "short" peut indifféremment être remplacé par "short int". De même, "long" peut être remplacé par "long int". Noter que le tableau ci-dessus correspond à la situation standard d un système 32 bits ; dans le cas d un système d exploitation fonctionnant sur une architecture 64 bits, l entier de type long sera généralement stocké sur 8 octets, soit 63 bits significatifs et un bit de signe, ou 64 bits significatifs. Le langage C définit également les données de type "int" (données signées) et "unsigned int" (données non signées). Selon les compilateurs, une variable déclarée "int" peut occuper 16 ou 32 bits en mémoire. 20

21 Dans le cas du compilateur cc disponible sur les ordinateurs des salles informatiques de l ESPCI, la convention utilisée est qu une variable "int" occupe 32 bits en mémoire. Il est très important de veiller à ce que toutes les opérations de manipulation des valeurs entières respectent le domaine de valeurs correspondant au type déclaré des données. Dans le cas contraire, le programme génère un débordement de valeur, ce qui se manifeste par une valeur effective qui n est pas celle attendue. Aucun message d erreur n apparaît dans ce cas. A titre d exemple, la table ci-dessous donne le résultat obtenu après addition de 1 à une valeur entière, en fonction du type de déclaration utilisé : Déclaration Valeur avant opération Valeur après opération (+1) short unsigned short unsigned short Ce genre d erreur à l exécution n est généralement pas sans conséquences pour le comportement ultérieur du programme. C est au programmeur de veiller à ce que ce genre de situations ne survienne pas! On peut citer ici quelques conséquences de ce genre d erreur, qui ont coûté (ou vont coûter) cher à la communauté : l explosion du premier lanceur Ariane 5 le 4 juin 1996 après 37 secondes de vol (coût : environ 800 millions ) le futur bug de janvier 2038, qui doit se produire le 19 janvier 2038, à 03:14:17 le bug de l an 2000, quoi que ce dernier soit d une nature un peu différente Les types de données réelles (à virgule flottante) Pour les nombres réels, on est souvent amené à utiliser une représentation sous la forme partie entière + partie fractionnaire ( mantisse ) + exposant l exposant étant généralement une puissance de 10. L ordinateur utilise une représentation similaire pour coder les nombres réels en mémoire, mais avec un exposant en puissance de 2. Les nombres réels sont donc stockés sous la forme mantisse x 2^ exposant Le codage interne des nombres réels (attribution d un rôle spécifique à chaque bit significatif) est défini par la norme internationale IEEE (the Institute of Electrical and Electronics Engineers), chaque compilateur devant normalement respecter cette norme. Le respect de cette norme est particulièrement important car il permet l échange d informations binaires entre des programmes écrits dans des langages différents, ou compilés avec des compilateurs différents. Attention, certains compilateurs ne respectent pas cette norme ; c est ainsi le cas de certaines versions anciennes de Turbo Pascal qui utilisent des réels sur 48 bits, alors que la norme IEEE ne définit que les réels simple et double précision sur 32 et 64 bits respectivement. Conformément à la norme IEEE, un réel 32 bits est codé comme suit : le premier bit le plus à gauche est le bit de signe (une donnée réelle ne peut pas être non signée), les huit bits suivants correspondent à l exposant ; la valeur est translatée de 0x7F, ce qui signifie que 0x7F correspond à 1.0 (exposant 0), 0x80 à 2.0 (exposant 1),... les 23 derniers bits représentent la mantisse. 21