SP1 Übungen - Milan Stephan

Aufgabenstellung *genau* lesen, auch die Hinweise.
Unnötige globale Variablen vermeiden.
Globale Variablen und Funktionen, soweit möglich, als static deklarieren.
Funktionen, die keine Argumente bekommen, in der Argumentliste mit void kennzeichnen.
Selber Testcases schreiben, besonders auf Randfälle prüfen!
Fehlerbehandlung (siehe man-Pages)
Jegliche durch malloc, fopen o.ä. angeforderten Ressourcen wieder freigeben (siehe valgrind).
Mit valgrind auf ungültige Speicherzugriffe prüfen (!)

Aufgabe 0: code (einzeln)

Nichts besonderes zu beachten :)

Aufgabe 1: lilo (einzeln)

insertElement, removeElement und main nicht als static deklarieren.
lilo Testcases

Aufgabe 2: wsort (Gruppe)

Eigene Wortlisten basteln
Systematisch verschiedene Wortlängen testen (besonders 97-103 Zeichen)
SEHR lange und sehr kurze Wörter testen
Auch mal Binärdaten reinwerfen
Die Ausgabe könnt ihr mit ./wsort <eingabeDatei >ausgabeDatei in eine Datei speichern
Ergebnisse mit der Referenzimplementierung vergleichen
(diff mitReferenzSortiert ausgabeDatei)
Bei diff bedeutet "keine Ausgabe", dass die zwei Dateien gleich sind
Fehlerbehandlung bei der Ausgabe (printf und fflush) nicht vergessen!
Eine Ausführung mit valgrind kann die wsort bei den großen Listen deutlich langsamer machen

Aufgabe 3: halde (Gruppe)

Bei dieser Aufgabe hilft euch valgrind nicht/kaum, da ihr die Speicherverwaltung selber baut
Zum Debugging mit Textausgaben nur write(2), kein printf/fprintf/... verwenden
Bei der Ausgabe eurer Freispeicherliste sind die Offsets interessant, weniger die absoluten Positionen
Auf Papier lassen sich verschiedene Szenarien gut durchspielen, die ihr mit eigenen Tests nachbauen könnt
Testet euer Programm ausführlich - besonders die Randfälle
Die laut Aufgabe geforderten Tests sind nicht ausreichend!
Lasst eure Tests jeweils mit einer neuen/sauberen halde starten - z.B. Fallunterscheidung in der main oder neue Prozesse starten (fork, kommt aber erst in der nächsten Aufgabe dran).
halde Testcases

Aufgabe 4: clash (Gruppe)

Verschiedenste Eingaben mit dem Ergebnis bei der Referenzimplementierung vergleichen
Spezifikation genau einhalten

Aufgabe 5: mach (einzeln)

Fangt mit der queue.c an und lest die Dokumentation der Funktionen genau
Semaphore mit Startwert 1 sind super für den gegenseitigen Ausschluss (P und V um den kritischen Abschnitt)
Startwert 0 eignet sich gut zum Zählen und für Benachrichtigungen (P und V von verschiedenen Threads)
Startwert n kann zum Begrenzen von Ressourcen verwendet werden
Kein aktives Warten - benutzt die Semaphore
Kritische Abschnitte so kurz wie möglich halten
Deadlock, Philosophenproblem

Aufgabe 6: creeper (Gruppe)

Bei allen Eingaben immer mit dem Ergebnis der Referenzimplementierung vergleichen (diff)
In der main braucht ihr (bis auf Fehler) keine Ausgaben machen; sollte alles in die creeper
Die Funktionalität für Dateien ./creeper datei1 datei2 -name=… ist ein guter Anfang
Bei Verzeichnisbäumen mit -depth=0 anfangen und nach und nach erhöhen
Es kann zu vielen Fehlerausgaben kommen, wenn ihr z.B. keine Rechte habt, Verzeichnisse zu lesen
Für mehr Übersichtlichkeit ggf. die Fehlerausgaben ausblenden: ./creeper … 2>/dev/null
Ein readdir Beispiel gibt's oben in der Tabelle
Mit der Rekursion aufpassen (. und ..)

Zusätzliche Compilerflags

Warum noch mehr Compilerflags? Wenn euch der Compiler durch genauere Prüfung schon vor Fehlern warnt, gebt ihr sie nicht mit ab. 😉

>> Wichtig: Der Code muss mit den "offiziellen" Flags kompilieren! <<

-std=c11 -D_XOPEN_SOURCE=700 -pedantic -Werror -Wall -g -Wextra -Wconversion -Wshadow -Wformat=2 -Wno-unused

Erklärung:

-g: Ermöglicht besseres Debugging mit valgrind oder gdb.

-Wextra: Schaltet noch mehr Checks an

-Wconversion: Weist auf implizite Casts hin, bei denen man Wertebereiche prüfen und ggf. abbrechen sollte

-Wshadow: Warnt bei überschriebenen Variablen (in Schleifen z.B.)

-Wformat=2: Erkennt kaputte/fehlende Format-Strings bei printf etc.

-Wno-unused: Unbenutzte Funktionen/Variablen/… ignorieren

Legende:

Immer anschalten
(Erstmal) weglassen, wenn ihr unverständliche Fehlermeldungen bekommt
Code muss auch ohne dieses Flag kompilieren, vor Abgabe sicherstellen!

Erkennen von Speicherlecks, Zugriffsfehlern usw.

Das Compilerflag -g verwenden, um Debug-Informationen mit ins fertige Programm zu schreiben. Nur so bekommt ihr Zeilennummern bei den Fehlerausgaben.

valgrind --leak-check=full --show-reachable=yes --track-origins=yes ./lilo

(Bei den Standard-Tests der lilo werden nicht alle Listenelemente wieder gelöscht, der Speicher daher nicht wieder freigegeben und dementsprechend von valgrind als Fehler erkannt.)

Pro-Tipp: Alias in euer Shell-Config (bei den meisten ~/.bashrc): alias "vg"="\valgrind --leak-check=full --show-reachable=yes --track-origins=yes"

So reicht es aus, vg ./wsort </proj/i4sp1/pub/aufgabe2/wlist0 >wlist0-my zu tippen.

Kontakt und Sonstiges

Bei Fragen zur Übung, zu euren Übungsaufgaben und deren Korrekturen (Korrekturrichtlinien) oder zu sonstigen SP-Themen könnt ihr mich gerne kontaktieren.

Mail: milan.stephan@fau.de

Discord: nud3ls4l4t

StudOn Kurs mit Forum (offiziell)

FSI-Forum (SP-Unterforum) (inoffiziell)

IRC-Guide, Jahrgangschannel #faui2k20 und #sp *

RocketChat der FSI Informatik, Jahrgangschannel #faui2k20 und #2_sp1

>> FAU Informatik Discord Server << (inoffiziell und auch für andere Studiengänge, die SP hören)

*Stef: Hilfe gibts nur hier™

Andere SP-Seiten:

Philip (T04)