Odin David

Certaines fonctionnalités mal aimées du C tendent à être également mal connues. Elles recèlent cependant souvent des applications inattendues.

Le langage C dispose d'opérateurs permettant de tester, modifier et effectuer des opérations au niveau du bit. Ces opérations sont souvent réservées à des utilisations restreintes, alors qu'elles sont ultra-rapides et ont des applications quelques fois insoupçonnées. Une restriction toutefois est que ces opérateurs ne s'appliquent qu'à des entiers (la plupart du temps non signés).

Le programme du jour permet de s'apercevoir que ce qui paraît simple au premier abord peut en fait regorger d'astuces aussi tordues les unes que les autres. Quoi de plus simple qu'une calculatrice ? Celle que Hou Qiming a proposé à l'IOCCC en 2011 semble bien innocente et pourtant...

La dernière fois, nous avons décortiqué un tableur ayant gagné l'IOCCC [1] en 2000. Aujourd'hui, nous allons analyser le complément idéal : un simulateur de vol, gagnant de l'IOCCC [1] en 1998.

Nous revenons aujourd'hui aux fondamentaux de cette rubrique avec l'analyse d'un code C ayant permis à monsieur Jari Arkko de gagner l'IOCCC [1] en 2000 dans la catégorie « Best Of Show ».Il s'agit donc d'un code source de moins de 1536 caractères non blancs qui réalise pourtant ce que des logiciels hors de prix peinent à imiter.

La dernière fois, nous avons réussi à décompresser le programme de Takashi Hayakawa pour lui donner une tête de programme PostScript presque normal.Aujourd'hui, nous allons décortiquer le programme décompacté, qui nous réserve pas mal de surprises avant d'être compréhensible.

La dernière fois, nous avons effleuré les possibilités offertes par le langage PostScript avec un petit programme même pas obfusqué. Aujourd'hui, nous plongeons dans le grand bain avec un programme beaucoup plus spectaculaire : un raytraceur auto-décompactable dont le décompacteur est compacté, complètement illisible de prime abord.

L'essence même de cette série est de décortiquer des codes qui ont été écrits par des programmeurs qui faisaient tout pour que leur code soit difficile à relire.Aujourd'hui, nous allons faire un énorme hors sujet, puisque nous allons essayer de comprendre un code que j'ai moi-même écrit il y a quelques années. Ceci dit, en retombant dessus, j'ai eu du mal à le relire alors que je n'avais pas fait grand chose pour le rendre illisible. C'est surtout le langage utilisé qui utilise des constructions non habituelles : le PostScript.

La dernière fois, nous avons décortiqué l'une des toute premières entrées de l'ioccc, avec un code datant de 1984. Aujourd'hui, nous allons étudier un bout de code nettement plus récent puisqu'il date de 2011, même s'il s'inspire d'une démo datant de l'Amiga (1986 ou 1987) !Rappelons que le but de cette rubrique est de rendre lisible un programme qui a pourtant été écrit de manière à être difficile à lire. Pour ce faire, nous allons petit à petit transformer un code source en un code équivalent, mais de plus en plus facile à déchiffrer.