Die Sprache C läßt dem Programmierer bei der Arbeit viel Freiheit - leider auch die Freiheit, Fehler zu machen. Ein großer Anteil der Programmierarbeit besteht so in der Fehlersuche. Arbeitet man mit einem Compiler, der über die normale Syntax-Prüfung hinaus wenig Unterstützung bei der Fehlersuche bietet, ist man darauf angewiesen, sich mit Hilfe von ‘printf’- und ‘scanf’- Aufrufen, mühselig an den Fehler heranzutasten.

Sehr problematisch wird diese Methode aber, wenn man unter GEM programmiert. Die eingestreuten printf-Befehle bringen den ‘Schreibtisch’ heillos durcheinander, und man tappt dann mit der Maus auf einem weißen Monitor herum, um die Programmknöpfe zu finden!

Nachdem mir diese Methode mehrfach die ganze Menüleiste zerstört hatte, überlegte ich mir, daß es wohl sinnvoller sei, den Problemen eines GEM-Programms mit den Mitteln zu begegnen, die GEM zur Verfügung stellt, nämlich den Dialogboxen. Diese haben ja den Sinn, dem Programmbenutzer Informationen über den augenblicklichen Zustand des Programms zu übermitteln (Helptexte, Fehlermeldungen). Anfangs verstreute ich die Alertboxen in der Nähe des vermuteten Fehlers direkt im Programm und entfernte sie nach dem Auffinden des Fehlers wieder. Als ich aber dann in einem besonders vertrackten Modul die Alertboxen mehrfach eingesetzt und wieder abgeräumt hatte, kam mir die Idee, sie doch zunächst einmal im Programm zu lassen und über eine globale Boolsche Variable ‘tr’ einen Trace - Modus zu simulieren.

Im kritischen Programmbereich haben die Funktionen dann folgendes Aussehen:

oder:

Die Funktion meldet sich dann bei eingeschaltetem Trace-Modus mit:

Bei diesem Vorgehen ist nach dem ersten Durchlauf klar, in welcher Funktion der Wurm steckt. Eine genaue Überprüfung dieser Funktion nach folgender Checkliste führt oft schon an dieser Stelle zum Finden des Fehlers:

1. Werden die GEM-Funktionen mit der richtigen Zahl von Parametern aufgerufen ??
2. Stimmen die Typen der übergebenen Parameter mit den von der Funktion erwarteten überein ??
3. Semikolon hinter ‘for’, ’while’ oder ‘if - Klammer ??
4. Zuweisungsoperator ‘=’ wo eigentlich ‘==’ stehen sollte ?
5. Hat sich ein Zeichen (z.B. ‘;’) ganz weit an den rechten Rand des Listings verirrt, so daß es beim normalen Durchscrollen des Quelltextes nicht zu erkennen ist??

Falls die Überprüfung dieser fünf Punkte keinen Erfolg bringt, sollte man sich als nächstes die folgenden Fragen vorlegen:

6. Sind alle Pointer richtig initialisiert ?
7. Sind alle Datenstrukturen richtig initialisiert ?

Zur Beantwortung dieser Fragen bieten sich nun die Funktionen an, um die es in diesem Artikel geht: ‘gprintf und ‘dump’:

Mit gprintf kann man sich den jeweils aktuellen Wert der Variablen in jedem Format ausdrucken lassen, das vom normalen ‘printf-Befehl erzeugt werden kann - dump erzeugt einen Hex-Dump von 4 mal 8 Bytes ab der angegebenen Speicheradresse. Den Aufruf dieser Funktionen macht man nun besser nicht von ‘tr’ abhängig, denn da man zu diesem Zeitpunkt die Lage des Fehlers kennt, wäre es sinnlose Zeitvergeudung, sich im Trace-Modus bis zur fraglichen Funktion durchzuklicken!

Angenommen ‘gprintf’ oder ‘dump’ zeigen für einen Pointer den Wert Null an. Nun ist es natürlich sinnvoll, das Programm an dieser Stelle zu unterbrechen - denn ein Nullpointer in Aktion macht den Griff zum Resetknopf unausweichlich. - Und wenn auch die benutzte Ramdisk resetfest ist, der Zeitverlust gegenüber einem geordneten Programmabbruch ist doch erheblich: Abfragedialog, ob Ramdisk so bleiben soll. Wiederaufbau des Desktops, Anzeige der Directories, Neustarten der Shell., also es st schon sinnvoll zu programmieren:

Falls ein Fehler behoben ist, kann man sich dann durch Anklicken von 'TRON’ zum nächsten Fehler durchklicken!!

Beschreibung der Funktionen

Die Funktion ‘gprintf’ entspricht veitgehend der normalen ‘printf’-Funktion. Nur daß die Ausgabe nicht auf dem vollen Bildschirm, sondern in kleinen Alertboxen mit je fünf Zeilen zu dreißig ASCII-Zeichen erfolgt. Es ist daher klar, daß Steuerzeichen im Formatstring und in Ausgabestrings nur mit Vorsicht zu verwenden sind.

Ist im Formatstring kein Zeilensprungzeichen ‘\n’ vorhanden, übernimmt gprintf automatisch die Zeilenverteilung und zwar so, daß nach jeder Ausgabe eines Variablenwerts eine neue Zeile angefangen wird. - Ist der Ausgabestring einer Variablen länger als 30 Zeichen, wird nach dem 30. Zeichen automatisch eine neue Zeile angefangen - andernfalls würde die Funktion form_alert Bomben erzeugen.

Hat man aber im Formatstring ein einziges ‘\n’ - Zeichen verwendet, ist man für die Verteilung auf die Zeilen selbst verantwortlich!! gprintf sorgt jetzt nur noch für den Zeilenwechsel nach dem 30. Zeichen. - Diese Betriebsweise von gprintf ermöglicht es zum Beispiel, mehr als eine Variable in eine Zeile zu packen.

Durch Verwendung des Alertbox-Zeilentrenners ‘|’ kann man zu den Zeilentrennern des Automatik-Betriebs weitere zusätzliche Zeilentrenner einfügen.

Insgesamt darf ein gprintf-Befehl 960 Zeichen ausgeben - natürlich verteilt auf mehrere aufeinanderfolgende Alertboxen.

Falls der ABBRUCH - Button angeklickt wurde, gibt geprintf den Wert 0 an die aufrufende Funktion zurück -andernfalls den Wert 2.

Die dump-Funktion verlangt als Argument eine Speicheradresse (also) long - Format. Sie erzeugt ein Hex-Dump von vier Zeilen zu jeweils 8 Byte ab der angegebenen Speicherstelle. In einer fünften Zeile werden 30 der 32 Bytes als Zeichenkette ausgegeben. Die letzten beiden Zeichen passen leider nicht mehr in die Box! Zeichen mit Ziffemcodes unter 31 und oberhalb 166 werden als Punkte ausgegeben.

Durch Anklicken des WEITER-Buttons können jeweils die nächsthöheren 32 Bytes des Speichers ausgegeben werden.

Variable Funktionsparameter

Der Quelltext ist ausführlich kommentiert und selbsterklärend. Eine Wiederholung der Kommentare an dieser Stelle würde keine zusätzliche Information bringen. - Lediglich die Argumentübergabe an gprintf muß näher erklärt werden. Da die Funktion gprintf Argumente unterschiedlichen Typs und in unterschiedlicher Anzahl verarbeiten muß, kann die normale Argumentübergabe hier nicht verwendet werden, gprintf macht sich bei der Argumentübemahme das Verfahren zunutze, mit dem die aufrufende Funktion die Argumente generell übergibt - nämlich über den “Stack”. Mit Hilfe der dump-Funktion läßt sich dieses Verfahren leicht demon-stieren:

Nehmen wir an, gprintf wird an irgendeiner Stelle des Programms mit den folgenden Argumenten aufgerufen:

Das Programm legt nun diese Argumente von rechts beginnend nacheinander auf den Stack: erst die vier Bytes der String-Adresse k, dann die vier Bytes der long-Variablen j , die beiden Bytes von i (int!) und dann die vier Adreßbytes der form_str - Variablen. Zuletzt wird die Rückkehradresse auf den Stack gelegt!! Dabei darf man nicht vergessen, daß der Stack von hohen zu niedrigen Speicheradressen - also nach unten wächst!!

gprintf kennt nun die Anfangsadresse dieses Stacks über die Adresse des ersten Arguments. In der Alertbox 2 ist das Hexdump dargestellt, das sich beim Aufruf von dump(&form_str) ergibt.

Die ersten vier Bytes enthalten die long - Zahl 9C276, nämlich die Adresse eben dieser Variablen ‘form_str’, danach folgen die Variablen i(1234)und k(22222222)sowie die Adresse des Strings k. (0009C1FC). Alertbox 3 geht der Adresse 9c276 nach und druckt prompt den Formatstring aus:

Um diese Variablen aber in der richtigen Weise übernehmen zu können, verfährt gprintf nun folgendermaßen: Zunächst einmal wird der Zeichenpointer ‘char *pargu’ auf die Anfangsadresse der zweiten Variablen ‘argu’ gesetzt. Durch die Analyse des Formatstrings erfährt die Funktion, daß es sich bei diesem Argument um den Typ ‘int’ handelt und übergibt diesen Sachverhalt an das im Programmkopf definierte Funktions-Macro ‘arg_wert’. Dieses erhöht nun den Wert des Pointers pargu um die Bytezahl einer int-Zahl: pargu += sizeof(int) (Da es sich um einen char-pointer handelt, funktioniert die Addition hier normal wie bei einer long-Zahl). Nachdem der Zeiger nun genau hinter die int-Variable i positioniert ist, wird er durch den Cast (int *) zu einem Zeiger auf ein array von int-Zahlen gemacht und mit (...) [-1] das hinter dem pointer liegende Element angesprochen.

Das gleiche Verfahren wird nun nacheinander mit den übrigen Argumenten durchgeführt. Man sieht aber, daß gprintf und natürlich auch printf selbst ganz schön durcheinander kommt, wenn die Zahl oder der Typ der im Formatstring angegebenen Argumente nicht mit der Zahl oder dem Typ der tatsächlich übergebenen Argumente übereinstimmt. In diesem Fall hat die Übergabe offensichtlich geklappt, denn gprintf gibt die folgende Alertbox aus:

Einbindung der Funktionen in eigene Programme.

Die Verwendung der Funktionen in eigenen Programmen sollte keine Probleme aufwerfen. Lediglich ‘tr’ muß als globale Variable im Programm deklariert werden und bei den Programmdefinitionen müssen die Funktionen: arg_wert(pargu, type) und Super(stack) enthalten sein. Ansonsten wird der Funktionsblock irgendwo ins Programm kopiert. Vielleicht kann er sich ja beim nächsten Bombenalarm schon nützlich machen.

Dr. Peter Härtel