Quelques messages d’erreur générés par le compilateur C MPW d’Apple (2006)

• Une page qui rassemble des messages d’erreur du compilateur C MPW d’Apple, présentés comme de véritables extraits obtenus en décompilant les ressources String du compilateur
• Au lieu de diagnostics de compilation ordinaires, ils transmettent les règles ANSI C, les contraintes de type et les erreurs de syntaxe avec des formulations mêlant blague et satire
• Les exemples incluent des erreurs du langage C concernant la longueur des littéraux de chaîne, les labels à l’intérieur d’un switch, l’emplacement de typedef, la combinaison volatile/register ou encore la modification d’une constante
• Certains messages visent directement des situations de compilation précises, comme la manipulation de void *, le transtypage de void, la redéfinition de struct, ou des erreurs impliquant goto et l’initialisation de variables automatiques
• Le compilateur pèse 324 KB ; il est ajouté que la liste publiée n’est peut-être qu’un extrait et que la question du droit d’auteur n’est pas claire

---

Recueil de messages d’erreur du compilateur C MPW

• Une page qui énumère certains messages d’erreur produits par le compilateur C MPW d’Apple
• Les messages sont présentés comme de véritables sorties, obtenues en décompilant les ressources String du compilateur
• Comme le compilateur pèse 324 KB, la liste n’est probablement pas exhaustive mais seulement un extrait
• Il est précisé que la question du droit d’auteur n’est pas certaine

Exemples de vrais diagnostics qui ressemblent à des blagues

• Messages qui tordent la syntaxe C et la norme ANSI

  • Limite de longueur des littéraux de chaîne :
    • "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
  • Erreur indiquant qu’il ne doit y avoir que des labels case ou default dans une instruction switch :
    • "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"
  • Cas où un nom typedef apparaît de façon inattendue :
    • "a typedef name was a complete surprise to me at this point in your program"
  • Message signalant, en citant une clause de l’ANSI C, que la cible d’un cast doit être de type scalaire :
    • "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)"

• Erreurs liées aux types et aux déclarations

  • Message indiquant que volatile et register ne peuvent pas être utilisés ensemble :
    • "'Volatile' and 'Register' are not miscible"
  • Formulation satirique pour dire qu’on ne peut pas modifier une constante :
    • "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"
  • Cas où l’on tente de redéfinir une struct déjà définie :
    • "This struct already has a perfectly good definition"
  • Restriction de cast liée à void :
    • "Can't cast a void type to type void (because the ANSI spec. says so, that's why)"
  • Message indiquant qu’on ne peut pas manipuler void * n’importe comment :
    • "can't go mucking with a 'void *'"

• Formulations d’erreur courtes ou exagérées

  • Erreur brève et directe :
    • "Huh ?"
  • Cas où une fonction déjà traitée réapparaît :
    • "we already did this function"
  • Long message d’erreur sur un goto venant de l’extérieur du bloc, une variable automatique avec initialiseur, et une fenêtre trop étroite pour tout afficher :
    • "This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message"
  • Cas où /* est trouvé à l’intérieur d’un commentaire :
    • "Call me paranoid but finding '/*' inside this comment makes me suspicious"
  • Cas où il y a trop d’erreurs sur une seule ligne :
    • "Too many errors on one line (make fewer)"
  • Erreur fatale de heap quand la table des symboles est pleine :
    • "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

[GN⁺]

Commentaires sur Hacker News

• L’époque où il y avait ce genre d’espièglerie dans l’informatique me manque
  Quand j’étais chez Amazon, mon manager m’avait raconté qu’autrefois, en mettant à jour la page 404, il avait scanné un dessin de chat fait par sa fille et l’avait mis dans le corps de la page. Quand je suis arrivé en 2009, cette image était encore là, mais à un moment quelqu’un a dû s’en apercevoir et la remplacer par une photo de chien issue d’une banque d’images. Pourtant, le nom de l’asset était toujours kayli-kitty.jpg, puis plus tard il a de nouveau été remplacé par des photos tournantes, et les traces de l’original ont disparu

  • C’est vraiment génial. Sur certaines pages 404 d’Amazon, par exemple https://www.amazon.co.jp/404, le nom de fichier est encore kailey-kitty.gif, mais l’image a été remplacée par une icône standard
    J’ai aussi retrouvé un commentaire de blog à ce sujet : https://www.davebellous.com/2006/09/25/what-the/#comment-290...
  • « Un compilateur de 324 ko », ce n’est pas seulement l’espièglerie qu’on a perdue. La bloatwareisation du logiciel atteint désormais un niveau comique
  • Je n’ai pas trouvé sur archive.org cette fameuse image de chat difficile à retrouver, mais j’ai trouvé cette image de chien à la place : https://web.archive.org/web/20030113144310/https://www.amazo...
    Il semble qu’Amazon ait introduit sa page d’erreur actuelle avec une grande image de chien vers juin 2016 : https://web.archive.org/web/20160612232820/http://www.amazon...
  • Ouvrez www.amazon.com et regardez tout de suite le source :)
  • Peut-être qu’une fois devenue majeure, sa fille a intenté un procès pour violation du droit d’auteur ;)
    Plus sérieusement, je me demande si ce serait possible, même si le tuteur avait donné son accord à l’époque

• « Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer » : ça rappelle l’époque où, même après avoir acheté un ordinateur, on pouvait encore acheter une mise à niveau de RAM
  Aujourd’hui, ce serait plutôt : « Symbol table full - fatal heap error; please go buy a new Mac with more RAM »

  • Pas forcément. Classic Mac OS ne prenait pas en charge la mémoire virtuelle, donc tout devait tenir en RAM, sauf si le programme écrivait lui-même sur disque les données qu’il n’utilisait pas
    Les systèmes d’exploitation modernes prennent tous en charge le swapping, donc la compilation continue, mais beaucoup plus lentement. Sur un ordinateur moderne, pour être réellement « à court de mémoire », il faut remplir à la fois la RAM et le disque
  • Je comprends l’argument autour de la mémoire unifiée des SoC, mais c’est quand même dommage. Même le nouveau Mac Pro n’a pas de slots RAM
  • Si vous voulez de la RAM évolutive, vous pouvez toujours utiliser un PC
  • De nos jours, c’est même encore plus vrai. Les Mac Apple Silicon peuvent stocker deux fois plus d’informations dans la même quantité de mémoire ; même une modeste configuration 8 Go peut donc contenir 16 Go de boilerplate FizzBuzz, 4 onglets Google Chrome, ou 20 % d’un node_modules moyen

• « a typedef name was a complete surprise to me at this point in your program »
  J’aimais l’époque où il existait des messages d’erreur de compilateur amusants. J’en ai vu un jour un comme celui-ci dans le compilateur d’un fournisseur : « No! But they'll only let me warn you. Danger Will Robinson! Danger! »
  Il y avait aussi : « Really! If you are fussing around with void *, just go home or at least back to your editor! ». Je crois que le responsable IT continuait à utiliser ce fournisseur à cause de ce message. Le SDK était moyen, mais c’était drôle

  • Je n’ai pas beaucoup programmé en C, et je me demande quel était le contexte : pourquoi void* était-il un si gros problème ?

• J’ai programmé sur le MacOS d’origine dès que cela a été possible. Je me souviens de beaucoup de ces messages d’erreur. En particulier : « Too many errors on one line (make fewer) »
  Je me souviens aussi des builds qui prenaient 45 minutes dès qu’un fichier d’en-tête changeait

  • À l’époque, je ne faisais que des extensions système, des plugins et des XCMD en mélangeant 68k, C et Pascal. Les projets étaient tous petits, donc le temps de compilation n’était pas un problème, et MPW était le paradis
    Mon plus gros XCMD contenait les trois langages, et MPW le liait sans broncher ; il était aussi facile d’automatiser des projets avec de petits blocs de code à coller dans un seul fichier. Je me souviens avoir franchement ri à chaque apparition d’un de ces rares messages d’erreur. Bravo à la personne qui les a écrits

• Après avoir utilisé ce compilateur pendant quelques années, j’ai fini par pouvoir « décompiler » mentalement à la volée le code objet 68k généré en code C, tant que la fonction n’était pas trop grosse
  Avec MacNosy, on pouvait généralement reconstituer les sources C d’une app en quelques heures. J’avais un script qui transformait le fichier MacNosy d’une app en fichiers assembleur et rsrc, puis je pouvais convertir les fonctions une par une en C tout en conservant une app compilable équivalente à l’original. Au début, je l’utilisais pour hacker des jeux, mais parfois aussi pour corriger des bugs
  Si la génération de code du compilateur MPW C était aussi prévisible, c’était en partie grâce à la symétrie du jeu d’instructions 68k. Ils ont fait un compilateur simple, et ça fonctionnait bien. L’essentiel des efforts allait ailleurs. Comme on pouvait prévoir assez précisément le code qui sortirait, si la génération ne plaisait pas, il suffisait de modifier le source. J’aime aussi le fait que le compilateur javac ait une philosophie similaire. Une fois qu’on connaît les motifs, on peut produire un bytecode presque optimal

• Le compilateur Glockenspiel C++ utilisé dans une entreprise de formation au début des années 90 était dérivé de cfront, et mon message d’erreur de syntaxe préféré était simplement « core dumped »
  C’était assez embarrassant à expliquer, dans le cadre d’un cours payant, à des stagiaires qui avaient déjà du mal avec C++ lui-même

  • L’utilisateur n’a qu’à lancer le débogueur et regarder la backtrace dans le fichier core. Ensuite, avec l’expérience, il apprendra à associer différentes adresses hexadécimales à différents types d’erreurs, donc ça ne peut pas faire de mal

• « Call me paranoid but finding '/*' inside this comment makes me suspicious » : ce n’est pas à vous de vous en soucier, monsieur le compilateur

  • Il m’arrive de me dire que ce serait bien que les compilateurs prennent en charge les commentaires de bloc imbriqués. Si un autre /* apparaît à l’intérieur d’un /*, il faudrait alors deux */ pour terminer, par exemple
    En réalité, c’est peut-être une idée horrible, mais il y a pas mal de situations où cela m’aurait fait gagner du temps

• C’est un peu à côté du contenu de la page, mais j’aimais vraiment la manière dont de nombreux utilitaires MPW généraient leurs sorties, y compris les messages d’erreur, sous forme de commandes
  Comme le terminal était un buffer d’éditeur, on pouvait remonter le curseur sur la ligne concernée, ou cliquer dessus, puis appuyer sur quelque chose comme cmd-enter pour ouvrir le fichier associé

  • Il me semble que l’exécution du texte sélectionné se faisait simplement avec la touche Entrée
  • Ça ressemble à Plan 9

• « a typedef name was a complete surprise to me at this point in your program »
  J’ai vu cette liste un nombre incalculable de fois, et pourtant ce message me fait toujours éclater de rire

  • C’est bien mieux que les « Redefinition of ... » ou « Static declaration follows non-static » de gcc

• Discussion précédente : https://news.ycombinator.com/item?id=30238928
  Pour ajouter un peu de contexte, le compilateur MPW C qui a produit ces messages n’a en fait pas été développé en interne par Apple, mais réalisé sous contrat par Green Hills Software[1]. C’est indiqué aussi sur la page Wikipedia[2] et dans sa source[3] ; amusant, cette source est précisément ce sujet
  [1] https://en.m.wikipedia.org/wiki/Green_Hills_Software
  [2] https://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Wor...
  [3] https://web.archive.org/web/20140528005901/http://lists.appl...