Einige Fehlermeldungen, die Apples MPW-C-Compiler (2006) erzeugte

 (cs.cmu.edu)
2 Punkte von GN⁺ 2023-08-28 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Seite, die Fehlermeldungen des MPW-C-Compilers von Apple sammelt; es heißt, es handle sich um echte Auszüge, die durch Dekompilieren der String-Ressourcen des Compilers gewonnen wurden
  • Statt gewöhnlicher Compilerdiagnosen vermitteln Sätze mit Witz und Satire Verstöße gegen den ANSI-C-Standard, Typbeschränkungen und Syntaxfehler
  • Die Beispiele umfassen C-Sprachfehler wie die Länge von String-Literalen, Labels innerhalb von switch, die Position von typedef, die Kombination von volatile/register und das Verändern von Konstanten
  • Auch bestimmte Kompiliersituationen werden direkt aufs Korn genommen, etwa Fehler rund um die Behandlung von void *, das Casten von void, die Neudefinition von struct sowie goto in Verbindung mit der Initialisierung automatischer Variablen
  • Der Compiler ist 324 KB groß; außerdem wird angemerkt, dass die veröffentlichte Liste möglicherweise nur Auszüge enthält und die Urheberrechtslage nicht ganz klar ist

Sammlung von MPW-C-Compiler-Fehlermeldungen

  • Eine Seite, die einige der vom MPW-C-Compiler von Apple erzeugten Fehlermeldungen auflistet
  • Die Meldungen werden als echte Ausgaben vorgestellt; laut Beschreibung wurden sie durch Dekompilieren der String-Ressourcen des Compilers gewonnen
  • Da der Compiler 324 KB groß ist, könnte die Liste eher ein Auszug als eine vollständige Sammlung sein
  • Zur Urheberrechtsfrage wird gesagt, dass man sich nicht sicher sei

Beispiele für echte Diagnosen, die wie Witze wirken

  • Meldungen, die C-Syntax und den ANSI-Standard verdrehen

    • Begrenzung der String-Literal-Länge:
      • "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
    • Fehlermeldung, dass innerhalb einer switch-Anweisung nur case- oder default-Labels stehen dürfen:
      • "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"
    • Situation, in der unerwartet ein typedef-Name auftaucht:
      • "a typedef name was a complete surprise to me at this point in your program"
    • Eine Meldung, die unter Verweis auf eine ANSI-C-Klausel darauf hinweist, dass das Ziel eines Casts skalar sein muss:
      • "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)"

  • Fehler rund um Typen und Deklarationen

    • Meldung, dass volatile und register nicht zusammen verwendet werden können:
      • "'Volatile' and 'Register' are not miscible"
    • Satirische Formulierung dafür, dass Konstanten nicht verändert werden können:
      • "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"
    • Situation, in der ein bereits definierter struct erneut definiert werden soll:
      • "This struct already has a perfectly good definition"
    • Cast-Beschränkung im Zusammenhang mit void:
      • "Can't cast a void type to type void (because the ANSI spec. says so, that's why)"
    • Meldung, dass man nicht beliebig mit void * hantieren darf:
      • "can't go mucking with a 'void *'"

  • Kurze oder übertrieben formulierte Fehlermeldungen

    • Kurze, direkte Fehlermeldung:
      • "Huh ?"
    • Situation, in der eine bereits bearbeitete Funktion erneut auftaucht:
      • "we already did this function"
    • Lange Fehlermeldung über ein goto von außerhalb des Blocks, eine automatische Variable mit Initializer und ein zu schmales Fenster auf einmal:
      • "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"
    • Situation, in der innerhalb eines Kommentars /* gefunden wurde:
      • "Call me paranoid but finding '/*' inside this comment makes me suspicious"
    • Situation mit zu vielen Fehlern in einer Zeile:
      • "Too many errors on one line (make fewer)"
    • Fataler Heap-Fehler wegen voller Symboltabelle:
      • "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-28
Hacker-News-Kommentare

  • Ich vermisse die Zeiten, in denen Computing noch diese Verspieltheit hatte
    Als ich bei Amazon war, erzählte mein Manager, dass er früher einmal die 404-Seite aktualisiert und eine von seiner Tochter gezeichnete Katze eingescannt und als Seiteninhalt eingefügt hatte. Als ich 2009 anfing, war dieses Bild noch da, aber irgendwann muss es jemand bemerkt und durch ein Stockfoto eines Hundes ersetzt haben. Der Asset-Name war trotzdem weiterhin kayli-kitty.jpg, und später wurde es wieder durch rotierende Fotos ersetzt, wodurch die Spuren des Originals verschwanden

  • „Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer“ – das erinnert an die alten Zeiten, als man nach dem Kauf eines Computers noch ein RAM-Upgrade kaufen konnte
    Heute hieße es wohl: „Symbol table full - fatal heap error; please go buy a new Mac with more RAM“

    • Nicht unbedingt. Classic Mac OS unterstützte keinen virtuellen Speicher, daher musste alles in den RAM passen, sofern ein Programm ungenutzte Daten nicht selbst auf die Festplatte auslagerte
      Moderne Betriebssysteme unterstützen alle Swapping, also läuft die Kompilierung weiter, wird nur deutlich langsamer. Um auf modernen Computern wirklich „zu wenig Speicher“ zu haben, muss man sowohl RAM als auch Festplatte füllen
    • Ich verstehe die Logik hinter dem Unified Memory in SoCs, aber schade ist es trotzdem. Selbst der neue Mac Pro hat keine RAM-Slots
    • Wenn man aufrüstbaren RAM will, kann man jederzeit einen PC verwenden
    • Heutzutage gilt das eher noch mehr. Ein Apple-Silicon-Mac kann bei gleicher Speicherkapazität doppelt so viele Informationen speichern, sodass selbst eine mickrige 8-GB-Konfiguration 16 GB FizzBuzz-Boilerplate, vier Google-Chrome-Tabs oder 20 % eines durchschnittlichen node_modules aufnehmen kann

  • „a typedef name was a complete surprise to me at this point in your program“
    Ich mochte die Zeiten, in denen es lustige Compiler-Fehlermeldungen gab. Früher habe ich bei einem Compiler eines Herstellers einmal diese Meldung gesehen: „No! But they'll only let me warn you. Danger Will Robinson! Danger!“
    Außerdem gab es noch: „Really! If you are fussing around with void *, just go home or at least back to your editor!“ Ich glaube, der IT-Manager blieb wegen dieser Meldung bei diesem Anbieter. Das SDK war nur so lala, aber es hatte Unterhaltungswert

    • Ich habe nicht besonders viel C programmiert; mich würde der Kontext interessieren, warum void* so ein großes Problem war

  • Ich habe, sobald es möglich war, auf dem ursprünglichen MacOS programmiert. An viele dieser Fehlermeldungen erinnere ich mich noch. Besonders an „Too many errors on one line (make fewer)“
    Ich erinnere mich auch daran, dass ein Build 45 Minuten dauerte, wenn sich eine einzige Header-Datei änderte

    • Damals habe ich mit einer Mischung aus 68k, C und Pascal nur Systemerweiterungen, Plug-ins und XCMDs gebaut. Die Projekte waren alle klein, daher waren Kompilierzeiten kein Problem, und MPW war ein Paradies
      Mein größtes XCMD enthielt alle drei Sprachen, und MPW linkte das völlig problemlos zusammen. Auch Projekte mit kleinen Codeblöcken, die in eine Datei eingefügt werden mussten, ließen sich leicht automatisieren. Ich erinnere mich, dass ich bei jeder seltenen Fehlermeldung laut lachen musste. An die Macher: gut gemacht

  • Nachdem ich diesen Compiler jahrelang benutzt hatte, konnte ich den erzeugten 68k-Objektcode, solange die Funktion nicht zu groß war, im Kopf spontan in C-Code „dekompilieren“
    Mit MacNosy konnte man den C-Quellcode einer App meist innerhalb weniger Stunden rekonstruieren. Ich hatte ein Skript, das die MacNosy-Datei einer App in eine Assembler-Datei und eine rsrc-Datei umwandelte, und konnte Funktionen eine nach der anderen nach C übertragen, während die App weiterhin äquivalent zum Original baubar blieb. Anfangs nutzte ich das zum Hacken von Spielen, gelegentlich aber auch für Bugfixes
    Dass die Codegenerierung des MPW-C-Compilers so vorhersehbar war, lag teilweise an der Symmetrie des 68k-Befehlssatzes. Man baute einen einfachen Compiler, und der funktionierte gut. Der Großteil der Arbeit floss in andere Bereiche. Da man ziemlich genau vorhersagen konnte, welcher Code herauskommen würde, konnte man den Quellcode ändern, wenn einem die Codegenerierung nicht gefiel. Mir gefällt, dass der javac-Compiler eine ähnliche Philosophie hat. Wenn man die Muster kennt, kann man nahezu optimalen Bytecode erzeugen

  • Der Glockenspiel-C++-Compiler, der Anfang der 90er bei einem Bildungsunternehmen eingesetzt wurde, war von cfront abgeleitet, und meine liebste Syntaxfehlermeldung war schlicht „core dumped“
    Das in einem bezahlten Kurs Teilnehmenden zu erklären, die ohnehin schon mit C++ selbst zu kämpfen hatten, war ziemlich unangenehm

    • Der Nutzer muss einfach den Debugger starten und sich im Core-File den Backtrace ansehen. Mit zunehmender Erfahrung lernt man dann, unterschiedliche hexadezimale Adressen unterschiedlichen Fehlerarten zuzuordnen; schaden kann es also nicht

  • „Call me paranoid but finding '/*' inside this comment makes me suspicious“ — darum sollten Sie sich nicht kümmern müssen

    • Manchmal wünsche ich mir, der Compiler würde verschachtelte Blockkommentare unterstützen. Also so, dass ein weiteres /* innerhalb von /* dazu führt, dass zum Beenden zweimal */ nötig ist
      In der Praxis wäre das vielleicht eine schreckliche Idee, aber es gab ziemlich viele Situationen, in denen es Zeit gespart hätte

  • Etwas abseits des Inhalts der Seite, aber mir gefiel sehr, wie viele MPW-Utilities ihre Ausgabe, einschließlich Fehlermeldungen, in Befehlsform erzeugten
    Weil das Terminal ein Editor-Buffer war, konnte man den Cursor auf die entsprechende Zeile setzen oder sie anklicken und dann etwa cmd-enter drücken, um die betreffende Datei zu öffnen

    • Ausgewählten Text auszuführen war, glaube ich, einfach die Eingabetaste
    • Sieht nach Plan 9 aus

  • „a typedef name was a complete surprise to me at this point in your program“
    Ich habe diese Liste unzählige Male gesehen, aber diese Meldung bringt mich jedes Mal laut zum Lachen

    • Viel besser als gccs „Redefinition of ...“ oder „Static declaration follows non-static“

  • Frühere Diskussion: https://news.ycombinator.com/item?id=30238928
    Als Kontext: Der MPW-C-Compiler, der diese Meldungen erzeugte, war tatsächlich keine interne Apple-Entwicklung, sondern wurde von Green Hills Software[1] im Auftrag erstellt. Das steht auch auf der Wikipedia-Seite[2] und in deren Quelle[3]; interessanterweise ist diese Quelle selbst genau dieses Thema
    [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...