Notes sur le langage C

C'est l'art de traduire un comportement en phrases simples et claires.

Surveiller la température.
Si elle dépasse la consigne, actionner une alarme.

Ces phrases sont ensuite traduites en 'pseudocode' qui est une sorte de langage de description des comportements (ressemble au Pascal) à base d'actions et de structures de code comme IF-ELSE-ENDIF, SELECT-CASE, REPEAT-UNTIL, WHILE, etc.

DO
   temperature := read_temperature()
   IF temperature > threshold
      alarm (ON)
   ENDIF
FOREVER

Ce pseudocode est ensuite traduit facilement en langage d'implémentation (par exemple en C).

{
   for (;;)
   {
      int temperature = read_temperature();
      if (temperature > threshold)
      {
         alarm (ON);
      }
   }
}

Il y a beaucoup de confusions sur les termes définition et déclaration en C. Voici un petit article qui va s'efforcer de mettre les choses au point.

II-A. Déclaration▲

extern int x;
<...>
{
   x = 2;
}

int x;
 
<...>
{
   x = 2;
}

{
   int x;
<...>
   x = 2;
}

int f();
 
extern int g(void);
 
static int h();
 
static int i(int a)
{
}
 
int j(char *b)
{
}

II-B. Définition▲

int a;
static float b[12];
{
   struct xxx c;
   static long d;
}

int f()
{
}
 
int g(void)
{
}

Sur un forum je pose une question sur le langage C et on me répond «va voir sur un forum consacré à ton système». M'enfin, je programme en C, c'est quoi ce cirque ?

III-A. Domaine couvert par le langage C▲

+--------+   +------------+   +--------+
| entrée |-->| traitement |-->| sortie |
+--------+   +------------+   +--------+

III-B. Fonctions système▲

MOV AH, 09h
   MOV AL, character
   MOV BH, 00h
   MOV BL, attributes
   MOV CX, 01h
   INT 10h

#if defined (__BORLANDC__)
#include <dos.h>
#else
#error Undefined for this platform
#endif
 
<...>
 
/* ---------------------------------------------------------------------
   VIDEO_putch()
   ---------------------------------------------------------------------
   écriture d'un caractère à la position courante du curseur avec
   la couleur spécifiée
   ---------------------------------------------------------------------
   E : caractère (0-255)
   E : couleur texte
   E : couleur fond
   S :
   --------------------------------------------------------------------- */
void VIDEO_putch (int c, eCOU ct, eCOU cf)
{
#if defined (__BORLANDC__)
   union REGS reg;
 
   /* caractere a écrire */
   reg.h.al = (uchar) c;
 
   /* putch avec attribut */
   reg.h.ah = 0x09;
 
   /* page 0 */
   reg.h.bh = 0;
 
   /* attributs 08h : clignotement */
   reg.h.bl = (uchar) (ct | ((cf & ~0x08) << 4));
 
   /* pas de repetitions */
   reg.x.cx = 1;
 
   /* Bios Video */
   int86 (0x10, &reg, &reg);
#endif
}

III-C. Bibliothèques tierces publiques▲

III-D. Bibliothèques tierces privées▲

Le langage C n'a à voir ni avec UNIX ni avec POSIX.

UNIX est une norme de spécification de système (actuellement UNIX 03) gérée par l'Open Group qui définit un système indépendamment de la machine sur lequel il tourne. Elle s'appuie, entre autres, sur la spécification des fonctions systèmes définie par POSIX.1 sous l'égide de l'IEEE.

Cette norme (POSIX.1) comprend à la fois la description d'un certain nombre de fonctions systèmes, et d'au moins deux types d'interfaces :

• le mode commande (shell) pour l'utilisateur de la machine ;
• une API utile aux programmeurs d'applications.

L'API est décrite sous la forme d'interfaces de fonctions appelables directement en langage C (C99 pour les dernières spécifications de POSIX.1). Les fonctions standards du C sont reprises telles quelles par POSIX.1.

Cette API est implémentée par une bibliothèque (.a, .so, .lib, .dll…) et des fichiers d'entête (.h) livrés avec les systèmes compatibles POSIX.1 (la plupart des unixoïdes, mais aussi certains Windows).

La spécification complète de POSIX.1 est disponible ici (s'inscrire, c'est gratuit et sans danger).

Les constructeurs de systèmes et de compilateurs s'efforcent de suivre tout ou partie de ces normes, ce qui permet une portabilité importante dans des domaines qui ne sont pas couverts par la norme du langage C comme :

• la gestion des répertoires ;
• la gestion des processus (process) ;
• la gestion des tâches (threads) ;
• la gestion des réseaux (sockets) ;
• etc.

Il existe de nombreuses implémentations du langage C. Certaines sont des interpréteurs, mais la plupart sont des compilateurs.

Compiler un programme consiste à vérifier le code source, puis à le traduire en langage machine de façon à en faire un fichier exécutable qui pourra ensuite être exécuté par la machine.

Les détails de production du code dépendent de l'implémentation, c'est-à-dire de la machine, du système, des outils utilisés, etc. Cependant, il existe une procédure générale commune à toutes ces implémentations :

• production de modules de code machine intermédiaires par compilation individuelle des codes sources. Il manque les références externes ;
• production du code machine exécutable par résolution des références externes (liens) entre les modules intermédiaires, et l'éventuel ajout de bibliothèques de fonctions selon les besoins.

Pour cela, on utilise successivement deux outils :

• le compilateur (compiler), autant de fois que nécessaire, selon le nombre de fichiers sources à traiter ;
• l'éditeur de lien (linker), une fois pour produire l'exécutable.

Le langage C définit 3 zones de stockage pour les objets (aussi appelés variables)

• la mémoire statique ;
• la mémoire allouée ;
• la mémoire automatique.

1 - Les objets définis hors des fonctions et les objets définis avec le mot clé static sont placés en mémoire statique. Leur durée de vie est celle de l'exécution du programme. Ils existent et sont initialisés (à 0 par défaut) avant même le lancement de main().

2 - Les objets définis avec les fonctions malloc(), calloc() et realloc() sont placés en mémoire allouée (appelée heap ou tas sur certaines implémentations). Leur durée de vie est contrôlée par le programme. Ils existent dès que l'appel de *alloc() retourne une valeur différente de NULL et cessent d'exister dès que free() est appelé avec la valeur retournée par *alloc().

3 - Les objets définis dans un bloc, sans qualificateur 'static', sont placés en mémoire automatique (appelée stack ou pile sur certaines implémentations). Leur durée de vie est celle du bloc dans lequel ils sont définis.

En C standard, la notion d'écran (et plus généralement de matériel) n'existe pas. Une application écrite en C est censée tourner sur une machine abstraite dont les interfaces matérielles sont vues comme des flux d'entrée ou de sortie. Ceci dans un souci de portabilité, qui est une des raisons d'être du langage C.

Parmi ces flux, il en existe 3 qui sont ouverts par défaut :

• stdin : entrée standard ;
• stdout : sortie standard ;
• stderr : sortie erreur.

Une application écrite en C peut être recompilée pour une multitude de plates-formes (qui diffèrent selon le processeur, l'architectures, le système, etc.) pour lesquelles stdin, stdout et stderr seront implémentés de manières différentes.

Sur un modem, par exemple, ces flux seront connectés à un port série permettant de brancher une console par laquelle on pourra passer, par exemple, des commandes AT.

Le but est d'instaurer un dialogue 'interactif' dans lequel l'application montre qu'elle attend une commande de l'opérateur à l'aide d'un 'prompt' ou 'invite de commande' :

modem> _

L'utilisateur peut alors passer une commande de numérotation :

modem> ATD0123456789
_

et le modem répond :

CONNECTED AT 9600 BAUDS

Il passe alors en mode transmission de données, et il signale qu'il n'attend plus de commandes par l'absence de prompt.

De même, sur un PC sous Windows ou unixoide, il est possible d'ouvrir une console localement ou de se brancher localement ou à distance sur la machine via une console (gestion, application, debug…). L'application ne verra pas la différence et continuera à attendre ses commandes de stdin et à envoyer ses réponses à stdout et/ou stderr.

L'avantage d'un tel système est qu'il exige très peu de la console, qui peut se réduire à un simple terminal série, voire à une imprimante série s'il ne s 'agit que de traces sur stdout ou stderr (utile pour mettre au point une application graphique, par exemple).

La gestion plein écran est une autre façon de concevoir la relation entre l'homme et la machine (IHM). En effet, on peut reprocher à l'interface console 'interactive', un certain manque de convivialité (largement compensé par le développement de langages 'scripts' extrêmement puissants), rendant les applications difficiles d'accès à un public non informaticien (direction, comptables, secrétaires, achats, commerciaux, etc.)

C'est pour cela qu'il a été développé la notion d'interface 'plein écran' qui permet d'améliorer l'ergonomie :

• effacement de l'écran ;
• placement absolu du curseur ;
• contrôle de la couleur du texte et du fond.

Malheureusement, il n'a jamais été prévu de norme internationale régissant cette gestion d'écran (probablement parce que faisant trop partie du domaine applicatif, chaque constructeur voulant tirer parti des performances de son matériel et de son logiciel).

Certaines pratiques et normes de fait se sont toutefois imposées.

• Basées sur les ressources de la machine :

  • PC/MS-DOS : Borland et sa bibliothèque conio (Turbo Pascal, C) pour la console intégrée. Windows bénéficie d'un portage réduit de conio pour MinGW (voir la documentation) ;
  • Unixoides : curses et ncurses. (consoles locales).

• Basées sur des ressources console :

  • Commandes ANSI (VT-100) ;
  • Vidéotex (Minitel) ;
  • HTML (Browser).

Je recommande la bibliothèque PDCurses qui est une version portable et multiplateforme de [n]curses et qui permet facilement de gérer les entrées/sorties directes à la console, et ce soit d'une manière basique à-la-conio, ou d'une manière plus avancée. Il existe de nombreux tutoriels sur le net.

Mention spéciale pour 'termcaps' qui est une bibliothèque multiplateforme censée s'adapter à quasiment tous les terminaux supportant des séquences d'échappement.

VII-A. Installation de ansi.sys sous Windows XP▲