SP1 Übungen SS21 - Milan Stephan (T09)
Stand: 1.7.
Übungen und Codeschnipsel (Folien und Videos)
lilo
wsort
clash
mach
creeper
Den 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
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 (siehevalgrind
). - Mit
valgrind
auf ungültige Speicherzugriffe prüfen (!)
Aufgabe 0: code
- Nichts besonderes zu beachten :)
Aufgabe 1: lilo
insertElement
,removeElement
undmain
nicht alsstatic
deklarieren.
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 >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
undfflush
) nicht vergessen! - Eine Ausführung mit
valgrind
kann diewsort
bei den großen Listen deutlich langsamer machen
Aufgabe 3: halde
- Bei dieser Aufgabe hilft euch
valgrind
nicht/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
halde
starten - z.B. Fallunterscheidung in dermain
oder 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.c
an und lest die Dokumentation der Funktionen genau - Semaphore mit Startwert 1 sind super für den gegenseitigen Ausschluss (
P
undV
um den kritischen Abschnitt) - Startwert 0 eignet sich gut zum Zählen und für Benachrichtigungen (
P
undV
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
- 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 diecreeper
- 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.
-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
lilo
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™