Sam et moi on se tape la compèt'. Je suis en train de finir mon code en utilisant une de ses optimisations, il a utilise une des miennes, on va voir a combien j'arrive, mais c'est prometteur, je devrais aussi etre en dessous des 200 octets.
En ce qui concerne le recouvrement des buffers, la situation simple est celle ou on ne connait pas la position du dernier litteral dans les donnees d'entree (il faudrait parser a l'avance et fournir l'info dans le format du fichier) et dans ce cas, recouvrir les donnees d'entree est dangereux: dans le cas limite, les 3 derniers octets pourraient etre un litteral. A l'inverse, on peut construire un cas ou il y a beaucoup de litteraux des le debut du buffer, mais avec de longues chaines de repetition de sorte que la sortie va submerger le buffer d'entree. Pour toutes ces raisons, j'ai du mal avec la notion de buffer in recouvert, sauf si on sait a l'avance que le buffer de sortie s'arretera avant la lecture du dernier litteral dans le buffer d'entree.
Cette info pourrait etre rajoutee dans le fichier dans le cas ou on aurait vraiment peu de ram a dispo. Mais comme on dit, "32 KB ought to be enough for everybody"
Lire les bits directement depuis la cassette permettrait d'eviter le buffer d'entree, de gagner du temps (decompression simultanee avec la lecture) et de la place (plus besoin de routine getbits). C'est un peu moins simple a faire sur MO5, car il faut respecter des timings stricts, mais sur cette machine, couple a un format cassette optimise, ca pourrait arracher.