Résistons à l’informatisation galopante de l’électronique !

Le langage que nous adorons détester a sa propre cérémonie : l’« International Obfuscated C Code Contest » s’est tenu pour la première fois en 1984 [1] afin de prouver que « good code is intuitively obvious upon casual inspection » en montrant les pires contre-exemples possibles dans un cadre restreint. La vingt-huitième édition vient de se conclure et la moisson est toujours aussi stupéfiante.

Le bit de parité est semblable à ce brave petit soldat qui sonne l’alerte, avec ses moyens réduits et quand il le peut, pour que la cavalerie vienne s’occuper du problème. Mais cet humble bit obéit aux lois de l’information et laisse passer une erreur sur deux. Grâce aux codes Gray, configurés de façon inhabituelle, nous pourrons mieux filtrer les erreurs, sans augmenter considérablement la taille du circuit ni déployer des théories (trop) complexes.

Quand on travaille avec de grandes quantités de bits, on n’a pas forcément envie de faire une interface graphique, et les afficher dans le terminal graphique n’est pas facile. Un bit occupe toute la place d’un caractère et la représentation hexadécimale n’est pas très parlante. Heureusement, Unicode est là !

Qu’est-ce qui caractérise un langage de haut niveau ? On peut dire que celui-ci doit au moins gérer les chaînes de caractères facilement et sans aucun risque. BASIC le faisait il y a soixante ans. N’importe quel langage courant le fait actuellement. Pourtant, le précédent article a démont(r)é [1] que le C n’en fait pas partie, surtout à cause des fonctions printf(3) et assimilées : elles procurent une illusion d’aisance qui s’effondre vite et c’est un vrai nid à failles. Nous avons suggéré quelques solutions que nous allons mettre en œuvre ici, grâce notamment au format des chaînes alignées [2] étendu avec des attributs, d’où le nom aStrA. Cela demande un peu de bricolage pour les réaliser en C, mais c’est un premier pas en avant, une base qui ne demande qu’à évoluer.