l'amphi-gouri

Le blog est resté presque un mois sans activité. J'étais en train d'apporter de grosses vagues de corrections au mémoire de thèse.

Ce billet est là pour vous dire une chose à propose de l'excellent et surpuissant programme valgrind, disponible sur Linux/x86, qui sert à détecter les problèmes dans tout programme, quel que soit son langage, du moment qu'il sagit d'un exécutable dynamiquement lié (presque tous sont ainsi). Pour ceux qui ne connaissent pas, valgrind fait tourner le programme testé dans une sorte d'environnement virtuel, dans lequel chaque accès à la mémoire est contrôlé. Toute tentative de lire ou d'écrire dans une zone de mémoire de façon anormale est détectée et rapportée, ainsi que tout un tas d'autres classes d'erreurs. En particulier, l'écriture juste à côté d'une zone allouée, ou dans une zone déjà libérée, etc...

Bien sûr on devrait tous programmer dans un langage de haut niveau comme OCaml (page de Xavier Leroy sur OCaml) ou Python. (Rappelons que ces langages eux-mêmes doivent bien être programmé en C pour être portables...). Le C est plus approprié pour des tâches de bas niveau, éventuellement avec des contraintes de temps réel comme on en a en robotique.

La chose que je devais dire sur valgrind est la suivante : même si valgrind sait détecter beaucoup de choses, soyez conscient qu'il ne peut détecter de petit débordement dans des tableaux qui sont alloués sur la pile (déclarés localement dans une fonction) ou bien statiques (déclarés de taille fixe comme variable globale à un fichier ou au programme). C'est écrit dans la FAQ de valgrind, question 5.2.

Bref : utilisez malloc au lieu de tableaux statiques ! Même si malloc() a un coût, et même s'il est notoire qu'il est inefficace sur certains systèmes (pas tous !), c'est tout de même la bonne façon de faire. Pensez aussi que malloc() peut être réimplémenté de façon plus efficace en conservant la sémantique. Bref : mieux vaut un programme correct et clair, et laisser la machine se débrouiller pour l'exécuter de façon performante, qu'une bidouille astucieusement rapide par endroit, mais impossible à faire marcher correctement et surtout à maintenir.

Mieux : au lieu de penser que vous êtes contraint de faire tout en C parce qu'une partie a des contraintes dans ce sens, préférez faire deux programmes : l'un en C qui fait la partie nécessairement en C, et l'autre en OCaml ou Python, qui communique avec la première par les moyens habituels (tubes, sockets, mémoire partagée...). Vous êtes d'autant plus gagnant que votre programme manipule des structures de données.