FAQ

Prüfung

Genaue Infos hierzu finden Sie auf der Seite Prüfung.

Übung

Die Anmeldung für die Tafelübungen findet in einer der ersten Wochen der Vorlesungszeit im Windhundverfahren statt: Waffel.

Ja. Die Zusammenarbeit in Gruppen ist nur möglich, falls sich alle Partner in der gleichen Übungsgruppe befinden.

Die Miniklausur entspricht einer "normalen" Übungsaufgabe mit maximal 15 Punkten. Berechnungsformel für die entsprechende Übungspunktezahl: PÜbung=12PMKP_\mathrm{Übung} = \frac{1}{2} P_\mathrm{MK}

Ja. Die Zusammenarbeit in Gruppen ist nur möglich, falls sich alle Partner in der gleichen Übungsgruppe befinden.

Oft sind Warnungen des Übersetzers ein Hinweis auf Fehler im Programmcode. Daher ist es zielführend, die Warnungen des Übersetzers nicht zu ignorieren. Manchmal hilft es aber auch zusätzliche Warnungen des Übersetzers zu aktivieren.

  • -Wextra: Einige zusätzliche Warnungen.
  • -Wshadow: Warnung, falls eine lokale Variable eine Variable eines äußeren Blocks verdeckt.
  • -Wformat=2: Zusätzliche Überprüfungen von Formatstrings
  • -Wlogical-op: Warnung bei potentiellem Vertauschen von logischen und bitweisen Operationen
  • ...und noch mehr

Beim Entkäfern deines Programms sind folgende Utensilien hilfreich. Einfache aber weniger mächtige Tools zuerst:

  • clang-format [--dry-run] -i myprogram.c: Editiert die Datei und formatiert den Code entsprechend eines einheitlichen Stils. Wenn Sie Probleme haben, ihren Code übersichtlich zu halten (Einrückung etc.) kann dies die Übersichtlichkeit erhöhen und die Fehlersuche beschleunigen. indent --linux-style source.c another_source.c erfüllt den selben Zweck, editiert jedoch nur Einrückung & Klammerpositionen.
  • clang-tidy myprogram.c findet Muster im Code die häufig in Programmfehlern resultieren. Einige Warnungen sind für die Entwicklung von POSIX-Konformen Programmen nicht hilfreich, verwenden Sie diese .clang-tidy Konfigurationsdatei um sie zu deaktivieren.
  • valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./mybinary: Prüft auf ungültige Speicherzugriffe und erkennt/lokalisiert Speicherleaks.
  • valgrind --tool=helgrind ./mybinary kann Synchronisationsprobleme finden. Achten Sie aber darauf, dass es hierbei zu false-positives kommen kann.
  • Durch das Compilieren mit -D_FORTIFY_SOURCE=1 in den CFLAGS werden Pufferüberläufe in Bibliotheksfunktionen teilweise erkannt.
  • Mit dem clang ThreadSanitizer können Wettlaufsituationen gefunden werden. Kompilieren und linken Sie hierzu Ihr Programm mit CC=clang und EXTRA_CFLAGS=-fsanitize=thread -g -O1 und führen Sie es aus.
  • Der clang AddressSanitizer kann ähnlich zu valgrind Speicherfehler finden. Kompilieren und binden Sie dazu Ihr Programm mit CC=clang, LD=clang, und EXTRA_CFLAGS=-fsanitize=undefined,leak,address,nonnull-attribute -fno-omit-frame-pointer -g -O1 und führen Sie es aus.
  • Compiler Explorer (godbolt.org) erlaubt es einem einfach zu sehen, zu welchem Maschinencode C Programme kompiliert werden und wie sich C in bestimmten Situationen genau verhält.
  • GDB: Der Debugger 😉

Bei Fragen zur Benutzung der Tools empfiehlt sich der Besuch der Rechnerübung. Welche Tools finden Sie am einfachsten und nützlichsten? Geben Sie uns Feedback!

Gitlab Tests

Voraussetzungen:
  1. Ihr habt Euch über Waffel für die Übung registriert.
  2. Ihr habt euch mit mkrepo ein GitLab Repository erstellt.
  3. Ihr habt in GitLab das Repository für die gewünschte Aufgabe ausgewählt.
Schritte:

Abbildung der Navigationsleiste in Gitlab. Der Menüpunkt "Build" ist aufgeklappt und "Pipeline" ausgewählt.

Im Menü auf der linken Seite, findet Ihr unter Build den Punkt Pipelines. Hier sind alle Pipelines, die je mit Eurem Code gelaufen sind.

Ansicht Pipeline-Übersicht. In Spalte "Pipeline" ist ein Eintrag zu sehen, dessen Überschrift hervorgehoben wurde.

Die Überschrift in der zweiten Spalte ist immer die entsprechende Commit-Message und wird Euch beim Klicken auch zum Commit bringen.

Listeneintrag in der Übersicht über alle Pipelines, der Status und die ID der Pipeline sind hervorgehoben.

In der zweiten Zeile findet Ihr die Pipeline ID oder IID. Außerdem ist in der ersten Spalte das Ergebnis der Pipeline zu sehen. Diese beiden Links bringen euch zur Pipeline-Übersicht.

Pipeline-Übersicht. Hervorgehoben sind der Tab "Tests" und der einzige Eintrag in der Liste "Jobs"

In dieser Übersicht findet Ihr jetzt einen Tab Tests, der Euch die Testergebnisse nach Test-Jobs sortiert präsentiert. Wir führen nur einen Test-Job aus, deswegen sollte hier nur ein Eintrag erscheinen. Den könnt Ihr klicken, um ausführlichere Ausgaben zu den ausgeführten Tests zu sehen.

Übersicht über gelaufene Tests, ein "View Details" Button ist hervorgehoben.

Hier seht Ihr nun eine Liste aller Tests, die ausgeführt wurden inklusive Status, ob ein Test durchgelaufen oder fehlgeschlagen ist. Hier könnt Ihr jetzt auf View Details klicken, um nähere Details zum entsprechenden Test zu bekommen.

Für gewöhnlich findet Ihr in View Details eine Ansicht wie diese: ein Szenario mit Given, When und Then Beschreibungen. Diese Begriffe sind Keywords aus dem Behavior Driven Development und beschreiben Vorbedingung (Given), Handlung (When) und Erwartung (Then). Wichtig: diese Ansicht zeigt Euch, an welcher Stelle genau der Test fehlgeschlagen ist (failed). In diesem Fall ist das Programm erfolgreich durchgelaufen, aber das erwartete Ergebnis unterscheidet sich vom tatsächlichen Ergebnis. Unter den Schritten findet Ihr dann meist noch weitere Details zur genauen Überprüfung, die fehlgeschlagen ist und Ihr seht sowohl das erwartete als auch Euer Ergebnis.

Nein. Wir testen Basisfunktionen ab und haben nicht die Mittel eine vollumfängliche Testsuite zu entwickeln. In SP lernt Ihr, an Randfälle zu denken und eventuelle Fehler zu behandeln. Das wollen wir euch auch nicht abnehmen.

Ja. Dieser Zusammenhang ist allerdings indirekt! Das heißt: wir bepunkten weiterhin wie vorher und der Pipeline-Status hat keinerlei Auswirkung auf Eure Punkte. Wir wissen allerdings aus Erfahrung, dass die Tests Euch helfen, an alles aus der Aufgabe zu denken und auf den ein oder anderen Randfall hinweisen. Es ist also wahrscheinlich, dass Ihr viele Punkte bekommt, wenn die Pipeline grün ist, aber eben nicht garantiert. Diesen Zustand finden wir selber nicht gerade optimal und arbeiten daran, dass grün auch zunehmend mit der Punktzahl korreliert.