# 2.4 Step Into

Quelle: https://inf.zone/lectures/2-arrays/short-2-4-debugging2/

> [!NOTE]
> Meldet der Debugger `Couldn't get CS register: Input/output error`, benutzen Sie wahrscheinlich einen Dev Container auf einem Rechner mit **ARM-Prozessor** (Mac mit Apple-Chip, Windows-Laptop mit Snapdragon), der noch in der alten Fassung für Intel und AMD läuft. So stellen Sie ihn um: [Dev Container auf ARM-Rechnern umstellen](https://inf.zone/extras/setup/devcontainer-arm/). Danach jedes Programm einmal mit `make` neu übersetzen. Bis dahin funktioniert der Debugger in [GitHub Codespaces](https://inf.zone/extras/setup/codespace-cloud/).

## Video

[Video ansehen](https://oc.streams.uni-bamberg.de/paella7/ui/watch.html?id=72abf19d-e32e-4877-b734-504ac2bc34c0)

### Alternativen

- [Video auf YouTube](https://youtu.be/lQflYVSAyj4)
- Download (1080p) (demnächst)
- Download (720p) (demnächst)
- Download (540p) (demnächst)

## Hinweise zu diesem Video

**Einordnung**

- Strings als char-Array (durchlaufen, `\0`, `strlen`, `strcmp`) sind Basis-Code. Das Video erklärt davon nur `strcmp`; alles Weitere steht in den [Notes 2](https://inf.zone/lectures/2-arrays/notes2/#strings).

## Was davon zur Basis gehört

Dieses Short zeigt vor allem ein Werkzeug: Debugger bedienen: Step Over gegen Step Into. Kein Schwerpunkt der Klausur, Sie brauchen es aber in den Übungen und in der Klausur.

- **Außerdem:**
    - **Basis-Code.** Strings mit strcmp vergleichen

Was die Labels bedeuten, steht unter [Was Sie zum Bestehen können müssen](https://inf.zone/extras/lernen/#was-sie-zum-bestehen-können-müssen).

## Material

- Folien und Transkript: unten auf dieser Seite

## Folien und Transkript

*Folientext aus den PDF-Folien, darunter jeweils der gesprochene Text des Videos. Der gesprochene Text ist maschinell transkribiert und nachkorrigiert, kann aber noch Fehler enthalten; im Video sprechen abwechselnd Prof und eine AI-Figur, die Sprecherwechsel sind nicht markiert. Die Zuordnung zu den Folien ist ungefähr. Die Zeitangaben verlinken auf die Stelle im Video (YouTube). Maßgeblich sind Video und Folien.*

### Folie 1 — Step Into

[PowerPoint-Original, Folie 1](https://inf.zone/lecture-section-shorts/2-arrays/2.4-step-into.pptx)

> PDF fehlt; Text aus der vorhandenen PowerPoint-Datei.

#### Transkript

> Nur eine Titelfolie vorhanden; der folgende Text umfasst das gesamte Video bzw. die Bildschirmdemonstration.

**[Video 00:00–00:25](https://www.youtube.com/watch?v=lQflYVSAyj4&t=0)**

Dies ist Inf-Einf-B. Heute Step Into. Willkommen zurück zu unserer Debugging-Serie. Heute widmen wir uns der Funktion Step Into des Debuggers. Und die gute Nachricht dabei ist, dass unser geschätzter Professor wieder bereitsteht als Versuchskaninchen für meine Erklärung. Ich gebe ihm Anweisungen und er wird sie befolgen. Also zumindest wird er das versuchen. Sehr witzig. Lass uns jetzt anfangen.

**[Video 00:25–00:57](https://www.youtube.com/watch?v=lQflYVSAyj4&t=25)**

Gut, dann los. Öffne bitte das Terminal und gib ./secret ein. Dieses Programm fragt nach einer geheimen Phrase. Versuche es zunächst mit Let me in oder mit Password. Du wirst sehen, dass keine dieser Eingaben eine Reaktion hervorruft. Nicht einmal das korrekte Passwort Please. Stimmt. Komisch, oder? Das ist wohl ein Fehler, also ein Softwarebug. Wir wollen mit dem Debugger herausfinden, was das Problem ist. Ich habe da schon einmal etwas vorbereitet. Du kannst den Quellcode von secret direkt im VS Code-Editor öffnen. Links neben der Zeile, in der wir die Benutzereingabe abfragen, legst du nun einen Breakpoint an.

**[Video 00:57–01:27](https://www.youtube.com/watch?v=lQflYVSAyj4&t=57)**

Wenn das geklappt hat, siehst du an der Stelle einen roten Kreis. Jetzt wird es spannend: Gib debug50 ./secret ins Terminal ein und führe es aus. Der Debugger startet und das Programm pausiert am Breakpoint. Zunächst verwenden wir Step Over, das wir im letzten Video kennengelernt haben. Nutze also die Step Over-Funktion in der Debugleiste oben oder drücke die Taste F10, um durch den Code zu gehen. Beobachte dabei die Variablenwerte im Debugfenster auf der linken Seite. Ist dir aufgefallen, dass phrase den Wert Please hat und correct auf false gesetzt ist?

**[Video 01:27–01:55](https://www.youtube.com/watch?v=lQflYVSAyj4&t=87)**

Was passierte, als du mit Step Over die check_phrase-Funktion ausgeführt hast? Komisch, correct ist immer noch false, obwohl wir das richtige Passwort eingegeben haben. Genau, mit Step Over konnten wir zwar den Code Schritt für Schritt ausführen, aber wir konnten nicht sehen, was in der check_phrase-Funktion passiert ist. Hast du vielleicht eine Idee, wie wir das Problem lösen? Ich habe so eine Vermutung. Könnte es sein, dass wir mit Step Into in die check_phrase-Funktion hineinschauen können? Stimmt genau.

**[Video 01:55–02:30](https://www.youtube.com/watch?v=lQflYVSAyj4&t=115)**

Gleich schauen wir uns damit die Funktion check_phrase genauer an. Aber bevor wir das tun, möchte ich noch kurz über die faszinierende Geschichte des Debuggings referieren. Wusstest du, dass der Begriff Bug auf Grace Hopper zurückgeht? Im Jahr 1947 fand sie eine Motte im Harvard Mark II Computer. [Anm.: Der Begriff „Bug“ für technische Fehler ist älter (belegt schon bei Edison in den 1870ern). 1947 fand das Team am Harvard Mark II eine Motte im Relais; Grace Hopper hat die Geschichte bekannt gemacht.] Könnten wir vielleicht beim Thema bleiben? Oh natürlich. Entschuldige meine Begeisterung für historische Fakten. Lass uns jetzt den Debugger neu starten und dieses Mal Step Into verwenden, wenn wir zur check_phrase-Funktion kommen. Führe wieder debug50 ./secret aus und gehe mit Step Over bis zur Zeile, wo check_phrase aufgerufen wird.

**[Video 02:30–03:01](https://www.youtube.com/watch?v=lQflYVSAyj4&t=150)**

Gut, jetzt verwenden wir nicht Step Over, sondern Step Into oder drücke die Taste F11, um in die Funktion reinzuspringen. Dadurch können wir uns die Anweisungen in der Funktion anschauen und so vielleicht den Grund für unser Problem finden. Ausgezeichnet. Nun befinden wir uns innerhalb der check_phrase-Funktion. Oh, da ist das Problem. Siehst du es? Was meinst du? Schau dir mal den Vergleich an. Ah, ein klassischer Anfängerfehler in C. Es sieht so aus, als ob wir zwei Strings vergleichen würden. Aber so funktioniert das in C leider nicht.

**[Video 03:01–03:29](https://www.youtube.com/watch?v=lQflYVSAyj4&t=181)**

Genau. In C können Strings nicht direkt mit dem ==-Operator verglichen werden, wie wir es von Zahlen gewohnt sind. Der Grund dafür ist, dass Strings in C als Zeiger auf den ersten Buchstaben des Strings implementiert sind. Wenn wir also == verwenden, vergleichen wir tatsächlich die Speicheradressen der Strings und nicht ihren Inhalt. Erinnerst du dich, was ich dir letztens gesagt habe? Du sollst bei deinen Erklärungen keine Konzepte verwenden, die wir noch nicht behandelt haben. Zeiger und Adressen.

**[Video 03:29–04:00](https://www.youtube.com/watch?v=lQflYVSAyj4&t=209)**

Behandeln wir erst später. Mit diesen Hinweisen lenkst du nur vom Thema ab und stiftest Verwirrung. In Ordnung. Jedenfalls vergleichen wir hier etwas anderes als den Inhalt der Strings und das ist der Grund, warum unser Programm nicht funktioniert, obwohl wir das richtige Passwort eingegeben haben. Die Speicheradressen von phrase und password sind unterschiedlich, auch wenn ihr Inhalt gleich ist. Jetzt lass das doch mal mit den Adressen. Die kommen noch früh genug. Alles klar. Ich erkläre jetzt noch schnell, wie man es richtig macht und dann gebe ich dir wieder Anweisungen. Das macht eh mehr Spaß, als Sachen zu erklären. Also.

**[Video 04:00–04:30](https://www.youtube.com/watch?v=lQflYVSAyj4&t=240)**

Um das Problem zu lösen, gibt es in C eine spezielle Funktion zum Vergleichen von Strings, strcmp. Man schreibt dann strcmp. Diese Funktion vergleicht den tatsächlichen Inhalt der Strings Zeichen für Zeichen. Passe den Vergleich doch bitte einmal an, sodass es passt. Sehr gut, bloß passt es halt jetzt immer noch nicht. Man könnte meinen, dass strcmp true zurückgibt, wenn die Strings identisch sind. Das stimmt aber nicht. strcmp gibt nämlich null zurück, wenn die Strings identisch sind. Daher müssen wir das Ergebnis mit null vergleichen.

**[Video 04:30–05:02](https://www.youtube.com/watch?v=lQflYVSAyj4&t=270)**

Wenn wir wissen wollen, ob die Strings gleich sind, baue das noch in den Code ein und dann schauen wir, ob das unser Problem löst. Großartig! Lass uns das Programm nun kompilieren und testen, um zu sehen, ob es jetzt wie erwartet funktioniert. Weißt du noch, was zu tun ist? Erst make aufrufen zum Kompilieren und dann das Programm starten. Nun wirst du wieder nach dem geheimen Passwort gefragt. Gib Please ein und lass uns sehen, was passiert. Perfekt. Wie du siehst, erhalten wir nun die Meldung Come on in. Unser Programm funktioniert jetzt wie erwartet. Lass mich kurz die vier Dinge zusammenfassen, die wir gelernt haben. Erstens.

**[Video 05:02–05:29](https://www.youtube.com/watch?v=lQflYVSAyj4&t=302)**

In C können Strings nicht direkt mit ist gleich ist gleich verglichen werden. Zweitens: Stattdessen verwenden wir die Funktion string compare für String-Vergleiche. Drittens: string compare gibt null zurück, wenn die Strings identisch sind. Viertens: Step into im Debugger half uns, diesen subtilen Fehler zu finden. Ich hoffe, diese Sitzung war hilfreich für Sie. Beim nächsten Mal werden wir uns eingehend mit der Geschichte des Debuggings. Ah, Mist! Ich hatte gehofft, dass du gerade nicht aufpasst.

**[Video 05:29–05:50](https://www.youtube.com/watch?v=lQflYVSAyj4&t=329)**

Dein Gesichtsausdruck deutet darauf hin, dass wir uns nächstes Mal wohl eher doch nicht mit der Geschichte des Debuggings beschäftigen werden. Danke, das war's für heute. Alles klar, du hast heute wirklich großartige Arbeit geleistet, toll. Schluss jetzt. Dies war Inf-Einf-B.
