SP1 Übungen SS21 - Milan Stephan (T09)
Stand: 1.7.
Übungen und Codeschnipsel (Folien und Videos)
lilowsortclashmachcreeperDen Zoom-Link gibt's im StudOn.
Evaluation (bis 10.7.)
>> Bitte in jedem Textfeld den Namen der Tutoren angeben, auf die sich das Feedback bezieht. <<
Bei den Tafelübungen den Namen des Tutors / Gruppennummer, bei den Rechnerübungen Tutor / Tag+Uhrzeit.
Checkliste für Abgaben
- Aufgabenstellung *genau* lesen, auch die Hinweise.
- Unnötige globale Variablen vermeiden.
- Globale Variablen und Funktionen, soweit möglich, als
staticdeklarieren. - Funktionen, die keine Argumente bekommen, in der Argumentliste mit
voidkennzeichnen. - Selber Testcases schreiben, besonders auf Randfälle prüfen!
- Fehlerbehandlung (siehe
man-Pages) - Jegliche durch
malloc,fopeno.ä. angeforderten Ressourcen wieder freigeben (siehevalgrind). - Mit
valgrindauf ungültige Speicherzugriffe prüfen (!)
Aufgabe 0: code
- Nichts besonderes zu beachten :)
Aufgabe 1: lilo
insertElement,removeElementundmainnicht alsstaticdeklarieren.
Aufgabe 2: wsort
- 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 >ausgabeDateiin eine Datei speichern - Ergebnisse mit der Referenzimplementierung vergleichen
(diff mitReferenzSortiert ausgabeDatei) - Bei
diffbedeutet "keine Ausgabe", dass die zwei Dateien gleich sind - Fehlerbehandlung bei der Ausgabe (
printfundfflush) nicht vergessen! - Eine Ausführung mit
valgrindkann diewsortbei den großen Listen deutlich langsamer machen
Aufgabe 3: halde
- Bei dieser Aufgabe hilft euch
valgrindnicht/kaum, da ihr die Speicherverwaltung selber baut - Zum Debugging mit Textausgaben nur
write(2), keinprintf/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
haldestarten - z.B. Fallunterscheidung in dermainoder neue Prozesse starten (fork, kommt aber erst in der nächsten Aufgabe dran).
Aufgabe 4: clash
- Verschiedenste Eingaben mit dem Ergebnis bei der Referenzimplementierung vergleichen
- Spezifikation genau einhalten
Aufgabe 5: mach
- Fangt mit der
queue.can und lest die Dokumentation der Funktionen genau - Semaphore mit Startwert 1 sind super für den gegenseitigen Ausschluss (
PundVum den kritischen Abschnitt) - Startwert 0 eignet sich gut zum Zählen und für Benachrichtigungen (
PundVvon verschiedenen Threads) - Startwert
nkann 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
- Bei allen Eingaben immer mit dem Ergebnis der Referenzimplementierung vergleichen (
diff) - In der
mainbraucht ihr (bis auf Fehler) keine Ausgaben machen; sollte alles in diecreeper - Die Funktionalität für Dateien
./creeper datei1 datei2 -name=…ist ein guter Anfang - Bei Verzeichnisbäumen mit
-depth=0anfangen 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
readdirBeispiel 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.
-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 ./lilolilo werden nicht alle Listenelemente wieder gelöscht, der Speicher daher nicht wieder freigegeben und dementsprechend von valgrind als Fehler erkannt.)~/.bashrc): alias "vg"="\valgrind --leak-check=full --show-reachable=yes --track-origins=yes"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: nudelsalat#8505
Rechnerübung: Dienstag 14-16 Uhr (Terminplan, RÜ-System) - oder, wenn gerade zu viel los ist 🙈
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
>> B.Sc. Informatik Discord Server << (inoffiziell, auch für andere Studiengänge, die SP hören)
*Stef: Hilfe gibts nur hier™