Conseils de codage en C/Robustesse des programmes

L'application de ces conseils suivants rendent les logiciels plus robustes : plus tolérants aux fautes.

Compilation stricte et outils qualité

Il faut compiler en utilsant les options les plus strictes, qui demandent au compilateur d’indiquer tous les avertissements et toutes les erreurs.

Il faut utiliser des outils qualité qui permettent d'effectuer encore plus de contrôle.

Il faudra ensuite comprendre les messages puis corrigez les sources afin d'éliminer tous ces avertissements.

Justification

Cette pratique permet d'obtenir des logiciels plus robustes et plus portables

Outils

• gcc avec les options -Wall -pedantic
• Outils de contrôle statique (syntaxique) comme splint, lint, proLint...
• Outil de contrôle dynamique (gestion des ressources à l'exécution) comme leaks, purify.

switch et clause default

Les instructions de choix multiple : (switch, case...) doivent comporter une clause pour les valeurs non testées individuellement (default);

Justification

Permet de traiter les cas non prévus explicitement en détectant les cas dégradés dus à des valeurs inattendues.

Ces valeurs peuvent provenir :

• de modifications non contrôlées d’une autre partie du code.
• d'un mauvais interfaçage de la fonction.
• d'une valeur non prévue reçue ou lue
• pour un appel système, à la compilation et de l'exécution sur un système non prévu.

Exemple (extrait)

//...
  while ((optc = getopt_long (argc, argv, "htvm", longopts, (int *) 0)) != EOF)
    {
      switch (optc)
	{
	case 'v':
	  v = 1;
	  break;
	case 'h':
	  h = 1;
	  break;
	case 'm':
	  m = 1;
	  break;
	default:
	  unknown = 1;
	  break;
	}
    }

Outils

• Les outils de vérification statique, comme splint, émettent un warning lorsqu'une clause default est oubliée.
• Un comptage des mots clés des mots switch et default dans un éditeur de texte ou avec les outils grep et wc d'UNIX.

Test des codes retours

Les codes de retour des fonctions et surtout des appels systèmes doivent être testés.

Justification

Les codes retournés par les fonctions peuvent signaler :

• des problèmes dans leur déroulement : validité des paramètres, erreurs de calcul...
• des erreurs dues à l’environnement du logiciel : non - conformité de l’arborescence des fichiers, droits d’accès, ressources non disponibles...

Ignorer ces problèmes peut conduire aux pires catastrophes.

Une bonne habitude consiste à caster en void tous les appels à des fonctions dont on souhaite ignorer les codes retour. Cette pratique facilite les contrôle avec les outils qualité.

Exemple

//...
        hFile = fopen(NOM_FIC, "r");
        if (hFile == NULL)
        {
                perror("Erreur");
                (void)fprintf(stderr,
                        "Impossible d'ouvrir %s en lecture\n",
                        NOM_FIC);
                exit(EXIT_FAILURE);
        }

Outils

Les outils de contrôle statiques comme splint émettent un warning lorsqu'un codes retour de fonction n'est pas testé ou explicitement ignoré.