Diskussion:Fehler in BASIC-ROM und KERNAL

Links zum Forum

Ich bin nicht so glücklich über die Links zum Bug-Thread des Forums. Der Thread besteht meiner Ansicht nach aus 38 Seiten Streiterei und 2 Seiten sinnvollem Inhalt (wobei die Qualität der Bugreports auch sehr unterschiedlich ist). Nachdem der Thread inzwischen dort nicht mehr gepinnt ist, dachte ich, dass es sinnvoll ist, die brauchbaren Inhalte rauszusuchen und hier zu sammeln und die Streiterei in die ewigen Jagdgründe des Internets wandern zu lassen. Mit den Links holt man diese aber eher wieder an die Oberfläche und zurrt sie da fest... --Berni (Diskussion) 14:26, 17. Feb. 2023 (CET)

Vorab: Die Seite finde ich grundsätzlich wunderbar und ist längst überfällig. Danke das du dir Mühe gemacht hast, damit zu beginnen.
Die Referenzen sind gezielt auf die entsprechenden Posts, die den jeweiligen Bug betreffen und sind nicht wahllos auf die Diskussion verstreut. Es geht nicht um die Streiterei, sondern um die Referenz an sich. Mehr ist es ja nicht. Es wird ja keiner gezwungen die Diskussion zu verfolgen, sondern es geht nur um den jeweils referenzierten Post.

Abgesehen davon ist ja nicht nur dieser Thread im F64 referenziert. Du kannst ja gerne auch andere Quellen zitieren, auch wenn man die Sachen selbst herausgefunden haben mag, gehört es zur Seriosität eines Wikis, dass man für Dinge, wenn möglich, mit Belegen untermauert oder vertiefende Informationen, etwas zur Historie und Diskussionen dazu liefert. Diese Einstellung etwas im Internet zu "verbannen" halte ich für eine grundlegend schlechte, weil wertende Bevormundung des Lesers und ist zumindest aus meiner Sicht abzulehnen. Nichts gegen Kritik und andere Sichtweisen, aber ein Wiki, wo man aus solchen Gründen Referenzen ablehnt, hab ich noch nicht gesehen und verwundert mich schon deutlich. --JohannKlasek (Diskussion) 23:54, 17. Feb. 2023 (CET)

Auch Vorab: Dir ein großes Dankeschön, dass du dir so oft die Mühe machst, neue Seiten gründlich durchzugehen und Links etc. einfügst. Beim Schreiben einer Seite ist man oft mit ganz anderen Dingen beschäftigt und denkt dann an solche Sachen oft einfach nicht.

Ja, danke, dafür ist ja unsere Community hier da. Das ist ja sozusagen "unser" Peer-Review-Prozess auf "Wiki". Ich muss ehrlich gestehen, dass ich für mich damit auch erst mal meinen Frieden machen musste, mit anderen zu arbeiten. Nicht dass du da ein Problem bei dir sähe, aber für mich war es jedenfalls eine Umstellung für die Texterstellung allgemein und bei mir kommen noch speziell die lausigen Flüchtigkeitsfehler dazu, die sich laufend einschleichen und die ich nicht los werde. Da bin ich mittlerweile sehr froh, dass zig andere ein Auge drauf haben. ;) --JohannKlasek (Diskussion) 13:35, 18. Feb. 2023 (CET)

Auch wenn wir hier nicht die Wikipedia sind, die Grundsätze zu Belegen halte ich auch hier weitgehend sinnvoll: Zum einen steht da, dass Belege nur auf zuverlässige Quellen verweisen sollen (ist ein Forumsthread eine zuverlässige Quelle?!?) und zum anderen, dass Belege nur dann notwenig sind, wenn zum Belegen Aufwand betrieben werden (eine Zeile eintippen ist eigentlich kaum Aufwand, oder?) muss oder die Aussagen strittig sind (hätte ich nicht gedacht, aber siehe auch die Diskussion unten...). Löschen, weil ein Beleg fehlt, halte ich her allerdings für keine gute Idee...

Was ich sagen will: Ich lehne die Referenzen nicht ab, ich denke nur, dass die zum Forums-Thread nicht sonderlich gut sind. Bessere Referenzen wollte ich ohnehin noch suchen.

Als Beleg zählt im Grunde alles, nicht nur Peer-Reviewed-Papers. Da hat man oft Blog-Artikel, Medienartikel, bei deren Inhalt auch nicht immer Echtheit garantiert werden kann. Aber darum geht auch nicht immer, es geht um die Vernetzung der Information, dass eine Aussage nicht "alleine" dasteht. Dass ein Forums-Post halt nicht so elegant daher kommt, noch dazu wenn drumherum diskutiert wird, ist halt zugegebenermaßen nicht die optimale Optik, aber solange man noch nichts besseres hat durchaus legitim. --JohannKlasek (Diskussion) 13:35, 18. Feb. 2023 (CET)

Und PS: Eigentlich hatte ich vor gehabt, im Wiki erst weiter zu schreiben, wenn ich mal einige von euch live kennengelernt habe (bin im März auf der DoReCo). Ich hatte schon letztes Jahr gemerkt, dass ich mit dieser Halb-Anonymität nicht gut klar komme. Aber dann musste ich diese Woche oft lange auf das Ergebnis eines Computerprogramms warten und hab' dann die Wartezeit doch genutzt, um hier was zu schreiben... --Berni (Diskussion) 10:04, 18. Feb. 2023 (CET)

Auch wenn es eine schöne Sache ist, einige der C64-Wiki-Autoren mal auf der DoReCo kennenzulernen. In den letzten 5 Jahren (auch vor Corona) habe ich es nicht mehr geschafft zur DoReCo zu kommen, weil die Termine für mich als Wechselschichtler sehr ungünstig lagen...

Auch sind nicht immer C64-Wiki-Autoren live vor Ort. Das war in den Anfängen der DoReCo mal anders...

Ich hoffe, dass es mir in Zukunft mal wieder gelingt. Wann wäre der nächste Termin denn?--Jodigi (Diskussion) 22:38, 18. Feb. 2023 (CET)

Ästhetik

Ich hatte mich schon häufiger gefragt, warum die Artikel über die BASIC-Befehle auf mich immer so unübersichtlich wirken. Mit den Änderungen hier ist mir klar geworden, was das ist: Diese Mischung aus Code-Blocks und Ausgabe-Vorlage passt nicht gut zusammen: Die Ausgabe sticht viel zu sehr hervor, die Code-Blocks gehen unter. --Berni (Diskussion) 14:26, 17. Feb. 2023 (CET)

Das hab ich ja fast erwartet ... Über die Ästhetik kann man tatsächlich immer vortrefflich streiten und mag ja auch Ansichtssache sein. Aber wir haben hier einen gewissen Weg eingeschlagen. Ob das wirklich soooo "unübersichtlich" ist, wie behauptet eine Sichtweise, mag zu einem gewissen Grad auch stimmen. Das rechtfertigt trotzdem nicht, das jeder sich in seiner Sichtweise verwirklicht. Wenn jeder seine persönlichen Präferenzen hier verwirklichen möchte, haben wir dann nur noch einen Flickenteppich an stilistischen Richtungen. Das nur grundsätzlich.
Aber um die Darstellung kompakter zu halten, können wir gerne in der "schlichten" Variante bleiben. An mir soll es nicht scheitern, ich wollte mal sehen, wie das in der sonst üblichen Form wirkt. Wenn sonst niemand sich dagegenstellt bzw. diesen stilistischen Spielraum als akzeptabel ansieht, bau ich das gerne wieder zurück. --JohannKlasek (Diskussion) 23:54, 17. Feb. 2023 (CET)

Ich weiß ehrlich gesagt nicht, was da sinnvoll ist. Ich finde Konsistenz durchaus sehr wichtig. Da bin ich auch bereit, mein eigenes Empfinden unterzuordnen. Mein Eindruck ist halt nur, dass dieses Hin- und Her auch anderen Leuten Probleme bereiten kann. --Berni (Diskussion) 10:06, 18. Feb. 2023 (CET)

Wie gesagt, es gibt glaub ich noch etliche Stellen, wo wir das Ausgabe-Makro noch nicht im Einsatz haben. So zwingend erscheint mir das auch nicht. Ich hätte es bedingt durch die Nähe zum BASIC-Befehlskomplex als recht passend gefunden. Aber so richtig in Stein gemeißelt ist das auch wieder nicht - andere möge mich da gegebenenfalls korrigieren - und eine schlichte Variante kann als legitimes Stilmittel, um eine gewisse Kompaktheit der Darstellung zu wahren, angesehen werden. Übrigens gefallen mir die Abstände beim Ausgabe-Makro auch nicht, was eben zu dieser "zerissenen" Darstellung führt. Das ärgert mich jedes mal, so hübsch an sich die Darstellung sonst auch ist. Vielleicht kann man das ja noch irgendwie hintricksen, damit das besser aussieht und damit auf einer technischen Ebene gelöst werden kann. --JohannKlasek (Diskussion) 13:35, 18. Feb. 2023 (CET)

Im folgenden Beispiel aus dem Artikel finde ich den Abstand zwischen BASIC-Text und Ausgabe zu groß:

F=FRE(0)
PRINT F, F-65536*(F<0)

-26634 38902 READY.

Das liegt allerdings nicht an der Ausgabe-Vorlage, sondern an der Wiki-internen Darstellung des BASIC-Textteils, wenn man diesen wie üblich mit führendem Leerzeichen darstellt. Die alternative Darstellung mit PRE und margin:0 vermeidet zwar den "übertriebenen" Abstand, doch die internen Links auf die BASIC-Befehle funktionieren im PRE-Block nicht mehr.

 F=[[FRE]](0)
 [[PRINT]] F, F-65536*(F<0)

-26634 38902 READY.

Eine brauchbare Lösung von diesem Problem habe ich leider noch nicht gesehen. --Petrus (Diskussion) 17:38, 18. Feb. 2023 (CET)

Kann man im Ausgabe-Makro den vertikalen "Margin" vielleicht mit einem negativen Wert nach "oben" ziehen. Eventuell eine zweite Ausgabe-Makro-Variante anlegen, die in Kombination speziell mit einem davor stehenden Code-Block verwendet werden kann? --JohannKlasek (Diskussion) 19:34, 18. Feb. 2023 (CET)

Wie wäre es damit?

F=FRE(0) PRINT F, F-65536*(F<0) -26634 38902 READY.

Zumindest bei Linux macht man das oft so, dass man Eingabe und Ausgabe einfach in ein Diagramm zeichnet. (Aber da hat man auch einen Eingabe-Prompt, den gibt es beim C64 natürlich so nicht.) Und die Links sehen doof aus, weil man sie fast nicht lesen kann... --Berni (Diskussion) 20:23, 18. Feb. 2023 (CET) PS: Wenn man ein zusätzliches Makro einrichten würde, das die Eingaben irgendwie hervorhebt und das man innerhalb der Ausgabe-Makros verwenden kann? (Andere Farbe, kursiv, oder sowas?) --Berni (Diskussion) 20:27, 18. Feb. 2023 (CET)

Ich habe jetzt in der Vorlage Ausgabe einfach "margin-top:0" ergänzt. Das sieht doch schon besser aus, oder? Achtung: auch die obigen Beispiele sind damit verändert!--Petrus (Diskussion) 20:32, 18. Feb. 2023 (CET)

Besser auf alle Fälle. Ich hab' noch CELLPADDING auf 0 gesetzt, jetzt ist der Unterschied am linken Rand nur noch ein Pixel (das ist Border=1 bei dem Code Teil, was aber bei der Ausgabe fehlt). Wenn man das noch anpassen könnte, wäre klasse. Ich weiß nur nicht wie... --Berni (Diskussion) 21:31, 18. Feb. 2023 (CET)

Token-Abkürzungen

Ich gebe zu bedenken, wird da nicht der Fehler provoziert durch bewusste Falscheingabe, weil man sich nicht genau ans blauen C64-Bedienungshandbuch hält, wo diese Token-Abkürzungen referenziert sind?

• Normalerweise werden die kleinen BASIC V2-Befehle mit 2 Zeichen abgekürzt, d.h. lI oder rU, wobei viele kleinere 2 bis 3-buchstabigen BASIC-Befehle keine Abkürzung kennen wie IF, die Funktionen TAN, SIN, COS, usw.
• Die längeren (ab ca. 5 Buchstaben oder länger) werden mit 3 Zeichen abgekürzt.
• Ausnahme wäre ja PRINT mit dem ?-Token, als einzige 1-Buchstaben-Abkürzung.
• Token-Abkürzungen sind genau wie die normal ausgeschriebenen BASIC-Befehle als Bestandteile von Variablennamen auch verboten, weil es dann Fehlermeldungen gibt, da der Interpreter den BASIC-Befehl ausführen will.

--Jodigi (Diskussion) 01:21, 18. Feb. 2023 (CET)

Auch hier gilt: Ein Software, die auch abseits der im Handbuch beschriebenen Eingaben unerwartete oder seltsames Verhalten zeigt, ist jedenfalls dokumentationswürdig. Das ist Bestandteil jeder Qualitätssicherung, eine Software mit Eingaben zu konfrontieren, die *nicht* im Handbuch steht, um ein unerwartetes, fehlerhaftes Verhalten einer Software zu ermitteln. Genau das ist der Grundstein für eine robuste Software.

Die Auflistung ist recht nett, aber das ist eben das, was algorithmisch der Tokenizerprozess macht und sich aus der Reihenfolge der Schlüsselwörter und deren jeweilige Länge quasi "automatisch" ergibt. Daraus ergibt sich zwangsläufig, dass bei 3-Zeichenschlüsselwörtern, wegen der Kodierung des letzten Zeichens und der Mindestlänge einer Abkurzung von 2 Zeichen zwangsweise eine Abkürzung eben nur 2 Zeichen sein kann.

Die SIN hat sehr wohl eine Abkürzung, nämlich sI, nur COS wird von CONT, TAN von TAB "überdeckt", weil die entsprechenden Schlüsselwörter früher gereiht sind.

Das ist ja der Zweck der Erwähnung hier, das unerwarteten Verhalten zu beschreiben.

--JohannKlasek (Diskussion) 02:13, 18. Feb. 2023 (CET)

Zeilennummer-Problematik

Auch interessant, allerdings wenn man sich an die gültigen Zeilennummervorgabe von 0 bis 63999 hält, würde das Problem nicht auftreten. --Jodigi (Diskussion) 01:28, 18. Feb. 2023 (CET)

Die korrekte Eingabe laut Handbuch zu fordern ist eine unrealistische Annahme - generell in der Softwareentwicklung. Eine Fehleingabe, auch wenn im unzulässigen Bereich (laut Manual), darf niemals zu einem Fehler führen oder das Handbuch weist das als definiertes Verhalten aus. Weder das eine noch das andere ist der Fall. --JohannKlasek (Diskussion) 01:43, 18. Feb. 2023 (CET)

Software narrensicher zu machen, ist wie immer die Aufgabe des Programmierers. Allerdings früher war es noch weniger möglich als heute, auch wegen der begrenzten Speicherkapazitäten.

Andererseits wenn im Handbuch die Vorgabe nachlesbar ist, sollte man es verinnerlichen und nicht das Unmögliche ausprobieren und sich danach zu beschweren, das es nicht funktioniert oder es nur Fehlermeldungen oder sogar Abstürze gibt.

Zitat aus dem C64-Bedienungshandbuch (S.32): "Als Zeilennummern können alle ganzen Zahlen zwischen 0 und 63999 gewählt werden."

--Jodigi (Diskussion) 01:53, 18. Feb. 2023 (CET)

Ernsthaft, bitte nicht einer Idealvorstellung nachhängen. Fehler bleibt Fehler. Ob früher wenig Platz war oder nicht, das ändert überhaupt nichts daran, dass es ein Fehler ist und damit die Software nicht robust ist oder ein Fehlverhalten aufweist. Es geht hier um die objektive Darstellung und nicht um Sympathiepunkte, die wir hier vergeben, weil die armen Programmierer früher von Ressourcenknappheit geplagt waren. Der Grund, warum ein Fehler auftritt, ist doch völlig irrelevant. Mit dieser Argumentation wird man den Standpunkt nicht verteidigen können (wozu auch immer da gut sein mag oder wer davon einen Nutzen haben soll ist mir unklar).

Abgesehen davon, faktisch alle Fehler werden erst bei gewissen, nicht dokumentieren Aufrufen provoziert, die erst damit eine nicht saubere Programmierung - nennen wir es Fehler, um das geht es doch, oder? - offenbaren. Das ist ja der Sinn und Zweck der Seite und soll kein Fan-Boy-Buch des Blauen Manuals sein. Dann würde die Seite "Abweichungen von der Spezifikation im User's Manual" lauten ... ;) --JohannKlasek (Diskussion) 02:26, 18. Feb. 2023 (CET)

Die Frage, die du hier (und auch bei den Tokens) aufwirfst ist: Was ist ein Bug? Die Definition hier im Wiki ist eher unbrauchbar, da steht im Wesentlichen: Ein Bug ist ein Programmierfehler. Die Definition in der Wikipedia ist hilfreicher: "Programmfehler [...] sind Begriffe [...], mit denen für Software-Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden."

Dass der Computer bei einem Tippfehler (350800 statt 35080 als Zeilennummer eingetippt) komplett abstürzt ist sicherlich kein "gewünschter Sollzustand" auch wenn nicht explizit im Handbuch erwähnt wird, dass der Computer bei der Eingabe einer Programmzeile niemals abstürzen kann.

Gleiches gilt auch für die Tokens oben. Was erwartest du bei der Eingabe "pokEprint#1,0"? Ich würde einen Syntax-Error, analog zur Eingabe "pokEprint1,0" erwarten. Stattdessen stürzt der Computer auch hier ab.

Problematischer sehe ich das bei FloatingPoint-Arithmetik: Da kann ein mathematisch falsches Ergebnis durchaus ein korrektes Ergebnis in FloatingPoint-Arithmetik sein, einfach aufgrund der Ungenauigkeit dieser Zahlen. Da muss man in jedem Fall genauer draufschauen. (Das mit dem 10*16777217 scheint mir allerdings tatsächlich ein Fehler zu sein.)

In dem Forumsthread wurde auch die Ausgabe von 3 Nullen bei "?syntax error..." als Fehler bezeichnet. Das ist zwar auch ein merkwürdiges Ergebnis, aber durchaus korrekt, da man beim Print-Befehl die Parameter nicht trennen muss und . eine valide Eingabe von 0 ist: Die Ausgabe besteht aus SY OR 0, 0 und 0. Sowas würde ich hier nicht mit aufnehmen; es sei denn, wir wollen einen Abschnitt mit Scheinfehlern haben. Wäre ich allerdings dagegen. --Berni (Diskussion) 09:36, 18. Feb. 2023 (CET)

Da möchte ich dir voll und ganz beipflichten. Und "Scheinfehler", nein danke! --JohannKlasek (Diskussion) 13:35, 18. Feb. 2023 (CET)

FRE-Funktion

"Der Wert des frei verfügbaren BASIC-Speichers wird zwar korrekt ermittelt, aber fehlerhaft in eine Fließkommazahl konvertiert, sobald der Wert 32767 übersteigt."

Bei den Unterpunkten, die ich schon überarbeitet habe, hatte ich versucht, den Anfang aus der Sicht eines BASIC-Programmierers zu schreiben, ohne dabei auf die internen Details einzugehen. Aus dieser Sicht ist das Ergebnis der FRE-Funktion einfach manchmal falsch; ob das zwischenzeitlich richtig berechnet wurde, spielt da, meiner Meinung nach, keine Rolle. Erst in den Abschnitten "Was geht schief?" bin ich dann immer auf die Interna eingegangen. Da steht das ja auch, dass es fehlerhaft konvertiert wird... Ganz analog müsste man bei den problematischen Zeilennummern ja sonst auch schreiben: Wenn eine zu große Eingabezahl gefunden wird, wird die Bearbeitung der Eingabe korrekt abgebrochen, aber beim Abbrechen kann es aber passieren, dass dann doch noch ein Fehler passiert. --Berni (Diskussion) 16:54, 24. Feb. 2023 (CET)

Das Ergebnis wird nicht falsche "berechnet". Der Ausdruck oder die Wortwahl ist irreführend oder lassen der Interpretation zu viel Spielraum. Die richtigen Zeiger werden herangezogen und die Differenz wird korrekt errechnet und bis zu einem gewissen Punkt noch korrekt übergeben. Es liegt schlichtweg an der Übergabe an das Interpreter-Framework, das dann zu falschen Zahlenrepräsentation führt. Daher halte ich generell für ungünstig, hier von "falsch berechnen" zu sprechen. So ist es eben einfach nicht.
Zudem kann man nicht so einfach alles auseinanderhalten, da die jeweilige Funktion oder ein Befehl mit Interpreteraufrufen verzahnt sind, wo es schwer ist eine exakte Grenze zu ziehen, was zu Funktion oder zu einem Befehl gehört und was dem umgebenden Interpreter zuzuordnen wäre. Das ist eine Ansichtssache, wo man vortrefflich Haarspalterei betreiben kann.
Die Darstellung lässt sich auch eindeutig in die korrekte Darstellung umrechnen.
Die Analogie mit den Zeilennummern ist nicht gegeben. Das eine ist in der Ausgabe, das andere in der Eingabe angesiedelt, sodass sich hier nur scheinbar eine ziemlich wackelige Analogie - künstlich fabriziert, nur um die Argumentation zu erfüllen - ergibt. Aber in Wirklichkeit befinden sich diese nicht wirklich auf der gleichen Ebene. --JohannKlasek (Diskussion) 15:23, 27. Feb. 2023 (CET)

Strings ohne Ende

Ist eigentlich auch nicht wirklich ein Fehler. Das ist eine (wenn auch ungewöhnliche) Eigenschaft des Parsers, wie etwa auch Leerzeichen zwischen Ziffern einer Zahl oder das optionale Semikolon bei PRINT-Argumenten, wenn String-Konstanten und Variablen sich abwechseln ungewöhnlich sein mögen:

PRINT "A:"A,"B:"B

vergleiche mit

PRINT "A:";A,"B:";B

Das BASIC-Programm verhält sich damit trotzdem absolut korrekt. Selbst wenn es eine BNF-Definition seitens Commodore für die Sprachsyntax gäbe, so würde ich das optionale Anführungszeichen vor einem Zeilenende nicht wirklich als Fehler ansehen. Das ist in etwa so, wie das optionale Semikolon beim letzten Statement eines Blocks in der Sprache C - da gäbe es vermutlich viele andere Beispiele in anderen Sprachen. Ich meine damit: Wo keine Definition vorliegt, kann auch nicht eine Abweichung einen Fehler darstellen. Noch dazu, wo das grundsätzliche Laufzeitverhalten dabei gar nicht berührt wird. Dass dabei im Handbuch eine unvollständige Definition oder generell saloppere Schreibweisen nicht erwähnt werden, ist dafür nicht ausschlaggebend und selbst das Commodore-Handbuch nicht wirklich eine vollständige und schon gar nicht korrekte Referenz oder Definition für das BASIC. Ich würde hier vorsichtig sein, ein User's Manual auf einen "Normen"-Status zu heben, auch wenn es ein von Commodore herausgegebenes Dokument handelt. ;) --JohannKlasek (Diskussion) 15:23, 27. Feb. 2023 (CET)

Kategorisierung wünschenswert

Super Seite hier, extrem nützlich und wertvoll für den modernen Retro-Programmierer, der ein Basic-Projekt auch bugfrei abschliessen möchte. Allerdings wäre bei den vielen Fehlern eine grobe Einteilung wünschenswert, um nicht jeden Pseudofehler unbedingt kennenlernen zu müssen. Wenn jemand bei einem Basic Befehl einen String übergibt, wo eigentlich eine Zahl stehen sollte, dann hat der Eilige eben nicht vorher die Befehlsreferenz studiert. Solche "Fehler" sind dann auch relativ leicht zu finden und zu eliminieren. Was kann der Interpreter dafür, wenn illegaler Ramsch eingegeben wird? Ein Auto fährt auch in den Graben, wenn man entsprechend stark am Lenkrad dreht. Aber ist dann das Lenkrad ein Fehler? Auch kannst du Diesel in ein Benzinauto einfüllen, aber ist dann der Benzinmotor ein Fehler? Im Gegensatz dazu gibt es aber echte Fehler, wie den Multiplikationsfehler und den Print-Befehl im Zusammenhang mit der Ausgabe von Zahlen. Solche Fehler findet der arglose Programmierer praktisch niemals jemals! Daran ist schon so manche Programmiererlaufbahn gescheitert...

Einmal vorweg: Bitte einen Kommentar immer mit --~~~~ aberschließen.

Also Pseudofehler sind das nicht, bloß weil sie im Normalfall und praktischen Einsatz faktisch nicht vorkommen. Wenn irgendwo eine Typüberprüfung fehlt, wo eigentlich eine sein sollte (und bei anderen Befehlen/Funktionen auch eine stattfindet), dann ist das dennoch ein Fehler. Die Vergleiche mit Auto im Graben und Tanken hinken ziemlich. Speziell beim Tanken haben moderne Fahrzeuge eine Sperrklappe, wenn man mit dem falschen Stutzen reingeht oder der Durchmesser des Zapfhahns passt gar nicht rein. Ein Fahrzeug wird deswegen nicht insgesamt nicht "fehlerhaft", wenn es diese Vorkehrungen nicht hat, aber es dann ein Fehler, wenn es gleichartige Modelle (oder analog andere Kommondos im gleichen Befehlsinterpreter) dieses Verhalten nicht aufweisen.

Aber wie auch immer, eine gewisse Einteilung bzw. Kategorisierung der Fehler in einer Tabelle am Anfang fände ich grundsätzlich nicht schlecht. Das kann man auch nach mehreren Kriterien machen. Da gibt es sich viele Klassifizierungsmöglichkeiten. ;) --JohannKlasek (Diskussion) 20:52, 18. Apr. 2024 (CEST)