SP2 Übungen - Milan Stephan

• Ein Makefile schreiben.
• Aufgabenstellung *genau* lesen, auch die Hinweise. Spezifikation genau einhalten!
• 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.
• Fehlerbehandlung! (Siehe man-Pages), Korrekturrichtlinien
• Jegliche durch malloc, fopen o.ä. angeforderten Ressourcen wieder freigeben (siehe valgrind).
• Beim Terminieren im Fehlerfall müssen die Ressourcen nicht wieder freigegeben werden.
• Mit valgrind auf ungültige Speicherzugriffe prüfen.
• Selber Testcases schreiben, besonders auf Randfälle prüfen!

• Rechtzeitig das Passwort für das SVN-Repository setzen.
• Doppelten Code vermeiden, Statuscode-Überprüfung in eine Funktion auslagern.
• Ihr könnt nc verwenden, um euer Programm zu debuggen, indem ihr mit nc -l 2345 in die Rolle des Mailservers schlüpft (faui03 und Port 2345 dementsprechend anpassen!)
• Die faui03 akzeptiert nur Mails aus dem Uni-Netz.
• snail-Proxy

• Webserver mit dem wwwpath aus dem Beispiel starten und testen, ob die Grafiken dargestellt werden
• Die Module können einzeln getestet werden, wenn sie mit den anderen Teilen der Referenzimplementierung zusammen gelinkt werden
• Fehlerbehandlung beim Schreiben auf die Netzwerkverbindung ist hier nicht notwendig (da SIGPIPE den Prozess im Fehlerfall terminiert und einzelne Anfragen mit fork in eigenen Prozessen abgearbeitet werden)
• Endian-Konvertierung: man byteorder
• (PSA) Es gibt doch keinen Proxy für den HTTP-Traffic (wie für SMTP bei der snail), weil:
  • Sich der Proxy gegenüber dem Browser anders verhalten könnte, als die sister
  • Würde nicht so viel bringen, da der Netzwerkverkehr nur aus der Anfrage und der Antwort besteht
  • Es wäre sehr unübersichtlich, wenn die Anfrage-Header des Browsers und der Antwort-Body im Terminal landen
  • Bilder im Terminal anzeigen (im Sinne von cat $bilddatei) ist nicht so cool
  • Man müsste beide Richtungen trennen, da sonst die Ausgaben "vermischt" werden (nach der Anfragezeile senden beide u.U. "gleichzeitig")

• Die Zusammenfassung "Signale" lesen - wenn Sachen unklar sind, gerne nachfragen! :)
• Mehrfach verwendeten Code in Funktionen auslagern
• Fehler, die nicht auftreten können (z.B. falsche Funktionsparameter bei garantiert gültigen Parametern), müssen auch nicht behandelt werden
• Ganz genau auf Race-Conditions zwischen Signalen und Hauptprogramm achten achten!
• Definierten Startzustand für die verwendeten Signalmasken und -behandlungen herstellen (die sind erstmal undefiniert!)
• Von der rush gestartete Kindprozesse sollen eine "sinnvolle" Umgebung bekommen (im Sinne der Vererbung von Signalmasken und -Behandlungen)

• Das Makefile wird länger als bei den anderen Aufgaben, plant hierfür bitte genügend Zeit ein
• Keine Ausgaben und kein exit in den "Bibliotheksfunktionen" (und sinnvoll Fehler behandeln)
• Auf korrekte Synchronisierung mit Semaphoren und atomic_compare_exchange_strong achten
• Wo braucht ihr volatile oder _Atomic?
• Strengere Compilerflags wie -Wconversion (siehe unten) können interessant sein

• Statt readdir könnt ihr auch scandir verwenden, aber readdir nochmal zu machen ist auch nicht verkehrt.
• Netzwerkdinge fehlerbehandeln, weil SIGPIPE den Prozess nicht terminieren darf!
• Was ist der Unterschied zwischen exit und _exit?
• Es geht einfacher, als opendir/readdir - schaut euch da mal die manpages an
• Statt dup könnt ihr fcntl mit F_DUPFD_CLOEXEC verwenden, um das Close-on-exec Flag atomar zu setzen (dup würde noch ein zusätzliches fcntl erfordern und ist damit nicht atomar).
• Die Race-Condition bei accept könnt ihr ignorieren - die bekäme man nur mit accept4 weg, das ist allerdings nicht POSIX-konform.

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: Fehler bei unbenutzten Funktionen/Variablen/… ignorieren

Legende:

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

Ignorieren vs Blockieren - oder auch: Behandlung vs Maskierung

Einrichtung der Signalbehandlung

static void handler(int signum) {
	(void) signum;

	int errno_backup = errno;

	// Die Signalbehandlung sollte *möglichst kurz* gehalten werden!
	// Falls die errno verändert werden könnte, vorher
	// sichern und danach wiederherstellen.

	errno = errno_backup;
}

int main(void) {

	struct sigaction action = {
		.sa_handler = handler,
		.sa_flags = SA_RESTART,
	};
	sigemptyset(&action.sa_mask);

	sigaction(SIGINT, &action, NULL);

	// [...]
}

Bearbeiten der aktiven, threadspezifischen Signalmaske

Erstellen und Bearbeiten von Sets

Beispiel zum Blockieren von SIGCHLD

int main(void) {
	sigset_t old;

	sigset_t mask;
	sigemptyset(&mask);
	sigaddset(&mask, SIGCHLD);

	sigprocmask(SIG_BLOCK, &mask, &old);

	// Kritischer Abschnitt - hier kann kein SIGCHLD auftreten.

	sigprocmask(SIG_SETMASK, &old, NULL);

	// Hier ist SIGCHLD -wie vorher- undefiniert!
	// SIGCHLD kann erlaubt oder auch blockiert sein.

	sigprocmask(SIG_UNBLOCK, &mask, NULL);

	// Hier ist SIGCHLD auf jeden Fall erlaubt.

	// [...]
}

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/#3_sp2

>> 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)