Quarante ans d’IOCCC : enfin les gagnants de l’édition 2024 !

L’exploration des algorithmes PEAC et de leurs applications se poursuit ! Le précédent article [1] avait abouti sur une fonction de checksum ultrarapide pour calculer l’empreinte d’un fichier. Cette fois-ci, nous irons plus loin en décortiquant d’autres réalisations pratiques, certaines complémentant les LFSR et d’autres les supplantant. Un petit tour du côté de POSIX nous rappellera qu’il est temps de tourner la page. Nous en profiterons même pour tâter un peu de VHDL : l’algorithme PEAC peut aussi sortir du monde logiciel ! On commence ici à s’approcher d’un « cookbook ».

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.

Je rêve d’un jour où la sécurité ne sera plus une option. J’ai donc commencé à mettre au point le modèle CDI [1] [2] : une architecture Harvard modifiée qui dédie un troisième espace d'adressage indépendant pour la pile de contrôle. Ce n'est pas la solution à tous les problèmes, mais ça y contribue beaucoup ! Pour preuve, un exploit récent divulgué à pwn2own [3] aurait facilement été stoppé par ce mécanisme. Mais cet exploit me sidère par son vecteur d'attaque que j’ignorais jusque-là : l'incontournable printf(3). Quand votre librairie standard inclut l’équivalent d’une machine de Turing, pour dynamiquement parser ou afficher du texte, ce n'est plus de l’idiosyncrasie mais de l'idiotie.