Allgemeines
Durch die aus medizinischen Gründen gebotene Einschränkung von Präsenzveranstaltungen wird der gesamte Übungsbetrieb durch ein virtuelles Angebot ersetzt. Dies umfasst sowohl die Tafel- als auch Rechnerübungen. Um an diesem Übungsbetrieb teilnehmen zu können, müssen sich alle Teilnehmer auf folgenden Plattformen anmelden:
- Anmeldung im Waffel (ab 25. Oktober 10:00 Uhr)
- Anmeldung im StudOn
Aufgrund des verkürzten Vorlesungszeitraums beginnt die Bearbeitung der ersten Aufgabe bereits in der ersten Vorlesungswoche. Um an der Übung teilnehmen zu können, ist eine vorherige Anmeldung im Waffel notwendig.
Die klassische Tafelübung wird durch eine Reihe von Lehrvideos ersetzt, die den Inhalt der Übung aufbereiten. Die Videos zielen darauf ab, das notwendige Wissen zur Bearbeitung der Übungsaufgaben zu vermitteln. Ergänzend dazu können im StudOn-Forum Fragen zum Inhalt gestellt werden.
Zusätzlich zu den Lehrvideos wird jeweils in der Woche nach einer Abgabe die Aufgabe mit dem Tutor nachbereitet. Dies wird mit einer Videokonferenz umgesetzt. Die Verbindungsdetails werden zu Beginn der Vorlesungszeit im StudOn-Kurs bekannt gegeben. Neben der Vorstellung und Besprechung einer Abgabe wird dabei auch auf individuelle Probleme eingegangen.
Da zum gegenwärtigen Zeitpunkt kollaboratives Arbeiten mit physischer Nähe unterbunden werden soll, können keine Rechnerübungen in den CIP-Räumen der Universität stattfinden. Stattdessen werden virtuell betreute Rechnerübungen angeboten. Alle Studierenden, die sich im Waffel-Kurs angemeldet und ihr SVN-Passwort gesetzt haben, können sich an der virtuellen Aufrufanlage eine Wartemarke zur Beratung ziehen. Dies ist nur zu den festgelegten Rechnerübungsterminen möglich. Details zur Funktionsweise werden in der ersten virtuellen Tafelübung besprochen.
Zur Information
- UNIX-Einführung der FSI-Informatik
Folien der Tafelübungennach oben ▲
All slides are copyrighted (C) 2011-2025 by Wolfgang Schröder-Preikschat and Jürgen Kleinöder, University of Erlangen-Nürnberg, Germany. Use without prior written permission of the authors is not permitted!
Kurzbeschreibung | Übungswoche | Videos | ||
---|---|---|---|---|
U1 | Netzwerkkommunikation, Sockets, POSIX-I/O vs. C-I/O, Aufgabe 1 | 02.11 – 06.11.2020 | ||
U2 | Netzwerkkommunikation, UNIX-Signale, Aufgabe 2 | 16.11 – 20.11.2020 | ||
B1 | Besprechung Aufgabe 1 | 23.11 – 27.11.2020 | ||
U3 | UNIX-Signale, Nebenläufigkeit, Duplizieren von Dateideskriptoren, Aufgabe 3 | 30.11 – 04.12.2020 | ||
B2 | Besprechung Aufgabe 2 | 07.12 – 11.12.2020 | ||
U4 | Thread-Synchronisation, Bibliotheken, Aufgabe 4 | 14.12 – 18.12.2020 | ||
B3 | Besprechung Aufgabe 3 | 21.12 – Mo., 21.12.2020 | ||
UH | Hacking | Di., 22.12 – Mi., 23.12.2020 | ||
U5 | Ringpuffer, Semaphore, Zusammenfassung, Aufgabe 5 | 11.01 – 15.01.2021 | ||
B4 | Besprechung Aufgabe 4, Klausurvorbereitung | 18.01 – 22.01.2021 | ||
UK | Klausurvorbereitung | 25.01 – 29.01.2021 | Klausur, Man-Pages | |
B5 | Besprechung von Aufgabe 5, Evaluierung, Klausurvorbereitung | 01.02 – 05.02.2021 |
Anfertigung, Abgabe und Bewertung der Übungsaufgabennach oben ▲
Soweit in der Aufgabenstellung nicht abweichend beschrieben, sollen alle abgegebenen Programme portabel zur SUSv4/POSIX.1-2008-Systemschnittstelle sein und im Sprachumfang dem C-Standard ISO C11 entsprechen. Alle Programme müssen mit folgenden Compileroptionen übersetzen:-std=c11 -pedantic -Wall -Werror -D_XOPEN_SOURCE=700
Die Abgabe erfolgt über die Rechnern im CIP-Pool mit dem Skript /proj/i4sp2/bin/submit und muss vor dem Abgabetermin erfolgen.
Dies kann über das Internet geschehen, sodass die Anwesenheit im CIP-Raum nicht notwendig ist.
Eine Abgabe per E-Mail oder USB-Stick ist grundsätzlich nicht möglich.
Zur Bearbeitung der Aufgaben wird Ihnen automatisch ein Projektverzeichnis
angelegt, nachdem Sie sich zu einer Übung angemeldet haben. Der Pfad
zu diesem Verzeichnis lautet /proj/i4sp2/LOGIN, wobei LOGIN
für Ihren Benutzernamen im CIP-Pool steht. Bitte bearbeiten Sie Ihre
Aufgaben in diesem Verzeichnis und verwalten Sie das Verzeichnis wie in
der ersten Aufgabenstellung beschrieben, da ansonsten das Abgabesystem
Ihre Lösung nicht finden kann.
Die abgegebenen Aufgaben werden von uns korrigiert und bewertet. Die Ergebnisse der Korrektur sind nach Login im Waffel einsehbar und können zusätzlich über das SVN abgerufen werden.
Übungsaufgabennach oben ▲
Die Übungsaufgaben für das komplette Semester stehen grob fest. Allerdings können sich bis zum Ausgabezeitpunkt noch Details an den Aufgaben ändern.Die verlinkten Aufgabenstellungen mit einem "Entwurf"-Wasserzeichen im Hintergrund stellen lediglich eine Orientierungshilfe dar. Die endgültigen Aufgabenstellungen werden spätestens am Ausgabetag verlinkt.
Alle Aufgaben werden den Korrekturhinweisen entsprechend bewertet.
Nr. | Titel | Kurzbeschreibung | Ausgabe | Bearbeitungszeit (Werktage) |
2er-Gruppen | Abzugebende Dateien | Zusatzinfos |
---|---|---|---|---|---|---|---|
1 | snail | Socket-Kommunikation (Client) | Montag, 02.11.2020 | 10 | Nein | snail.c, Makefile | |
2 | sister | Socket-Kommunikation (Server), Signale, Makefile | Montag, 16.11.2020 | 11 | Ja | sister.c, connection-fork.c, request-http.c, Makefile | API-Dokumentation |
3 | rush | POSIX-Signale, Filedeskriptoren, Nebenläufigkeit | Montag, 30.11.2020 | 11 | Ja | Makefile, rush.c | API-Dokumentation |
4 | jbuffer | Semaphore, nicht-blockierende Synchronisation, Bibliotheken | Montag, 14.12.2020 | 11 | Nein | jbuffer.c, sem.c, Makefile | API-Dokumentation |
5 | mother | Socket-Kommunikation (Server), POSIX-Threads, Verzeichnisse, Prozesse, Signale | Montag, 11.01.2021 | 11 | Ja | connection-mt.c, request-httpx.c | API-Dokumentation |
Literaturempfehlungennach oben ▲
Einführung in die Programmiersprache C
- Stephen Kochan: Programming in C. Sams Publishing, 3rd Edition, 2005.
- Karlheinz Zeiner: Programmieren lernen mit C. Carl Hanser, 4. Auflage, 2000.
- Steve Oualline: Practical C Programming. O'Reilly, 1991.
- Peter Darnell, Philip Margolis: C: A Software Engineering Approach. Springer, 1991.
- Brian Kernighan, Dennis Ritchie: The C Programming Language. Prentice Hall, 1988 (in der deutschen Übersetzung 1990 bei Hanser erschienen)
UNIX-Systemprogrammierung
- A. S. Tanenbaum, A. S. Woodhull: Operating Systems: Design And Implementation, Prentice Hall, 1997.
- R. W. Stevens: Advanced Programming in the UNIX Environment. Addison-Wesley, 1992.
Übersicht aller angebotenen Tafelübungennach oben ▲
T01 | Bender, Kilian | Mo 10:15 - 12:45 | Zoom-Meeting |
T02 | Schärtl, Andreas | Mo 12:15 - 13:45 | Zoom-Meeting |
T03 | Weidner, Johannes | Di 08:15 - 09:45 | Zoom-Meeting |
T04 | Kaludercic, Philip | Mi 08:15 - 09:45 | Zoom-Meeting |
T05 | Krebs, Jonathan | Mi 14:15 - 15:45 | Zoom-Meeting |
T06 | Windsheimer, Felix | Do 10:15 - 11:45 | Zoom-Meeting |
T07 | Rabenstein, Jonas | Do 12:15 - 13:45 | Zoom-Meeting |
T08 | Bläse, Fabian | Do 14:15 - 15:45 | Zoom-Meeting |
T09 | Schärtl, Andreas | Fr 08:15 - 09:45 | Zoom-Meeting |
T10 | Schöninger, Stefan | Fr 14:15 - 15:45 | Zoom-Meeting |
Übersicht aller angebotenen Rechnerübungennach oben ▲
Alle Rechnerübungen werden in Form von Jitsi-Videokonferenzen abgehalten. Die im Dialog stattfindende Übung wird über eine virtuelle Aufrufanlage verwaltet. Hier werden alle Anfragen gesammelt und der Reihe nach abgearbeitet. Zur Anmeldung müssen Sie bereits ihr SVN-Passwort gesetzt haben.
Anleitungen zur Bedienung von Jitsi werden vom RRZE bereitgestellt.
Rechnerübungen zu Systemprogrammierung 1 und 2 (RÜ SP)
- Verantwortliche
- Dustin Nguyen, M. Sc., Jonas Rabenstein, M. Sc.
- Angaben
- Übung
Online
2 SWS
Frühstudium, Sprache Deutsch
- Studienfächer / Studienrichtungen
- PF CE-BA-G 3
PF INF-BA 3
PF IuK-BA 3
PF WINF-BA 3
WPF MT-BA ab 5
| Jonas Rabenstein Dustin Nguyen | |||||||||||
| Jonas Rabenstein Dustin Nguyen | |||||||||||
| Jonas Rabenstein Dustin Nguyen | |||||||||||
| Jonas Rabenstein Dustin Nguyen | |||||||||||
| Jonas Rabenstein Dustin Nguyen | |||||||||||
| Jonas Rabenstein Dustin Nguyen |
Korrekturhinweise nach oben ▲
Die in den Aufgaben beschriebenen Anforderungen müssen durch das Programm erfüllt sein, damit Bonuspunkte gesammelt werden können. Dazu gehört auch, dass alle angeforderten Ressourcen beim erfolgreichen Beenden des Programms wieder freigegeben werden; im Fehlerfall müssen keine Ressourcen freigegeben werden. Für jeden Fehler in der Implementierung werden Punkte von der maximal erreichbaren Punktzahl abgezogen.
Jede Datei (C-Datei oder Makefile) gilt als eigenes Modul. Punkte werden in dem Modul abgezogen, wo laut Aufgabenstellung die Funktionalität zu erwarten ist. Jedes Modul wird mit mindestens Null Punkten bewertet. Die maximalen Punkte pro Modul stehen in der Aufgabenstellung.
Die folgenden Korrekturrichtlinien zeigen wofür und in welchem Ausmaß Punkte bei Fehlern abgezogen werden. Sie sind als Richtlinien zu verstehen und nicht vollständig. In Ausnahmen kann davon abgewichen werden. Falls nicht weiter spezifiziert wird für jedes Auftreten eines Fehlers die genannten Punkte abgezogen, auch mehrfach für denselben Fehler an unterschiedlichen Stellen im Programm. Tritt derselbe Fehler mehr als zweimal auf, so gibt es ab dem dritten Auftreten keinen Punktabzug mehr und er wird als Folgefehler gewertet.
Eine gekürzte Variante der Korrekturhinweise steht als Cheatsheet zum Drucken zur Verfügung.
Makefile
Fehlerbild | Punktabzug | Anmerkung |
---|---|---|
.PHONY fehlt oder unvollständig |
0,5 | Ausnahme: halde, dort optional da noch nicht eingeführt |
all (oder Entsprechung) ist nicht erstes Target |
0,5 | Ausnahme: halde, dort optional da noch nicht eingeführt |
Abhängigkeit(en) fehlen | 0,5 | pro Target |
Auf der Webseite geforderte Compilerflags fehlen | 0,5 | pro Compileraufruf |
CFLAGS oder CC werden nicht genutzt, obwohl in der Aufgabenstellung gefordert |
0,5 | pro Variable |
Übersetzerfehler
Wenn sich ein Programm nicht übersetzen lässt werden vom jeweiligen Modul
Punkte abgezogen. Für jeden Auslöser von Übersetzerfehlern werden Punkte
abgezogen. Dies betrifft auch vom Übersetzer ausgelöste Warnungen, da mit
-Werror
kompiliert wird.
Fehlerbild | Punktabzug |
---|---|
Auslöser eines Übersetzerfehlers | 3 |
Falsche oder unzureichende Fehlerbehandlung
Nutzung von C- und POSIX-Funktionen erfordern korrekte Fehlerbehandlung.
Mögliche Fehler sind in der man
-Page der betreffenden Funktion
nachzulesen.
Alle Funktionen benötigen Fehlerbehandlung, außer die
Funktion kann nicht fehlschlagen. Ob eine Funktion fehlschlagen kann, richtet
sich nach der POSIX Spezifikation (man 3p
funktion
).
Für jede falsche oder nicht ausreichende Fehlerbehandlung werden Punkte
abgezogen. Typische Bestandteile einer Fehlerbehandlung sind:
Nötige Fehlerbehandlung | Punktabzug |
---|---|
Prüfen auf Fehler | 0,5 |
falls errno zur Fehlerprüfung genutzt wird, obwohl laut Man-Page nicht vorgesehen |
0,5 |
Ausgabe des Fehlergrunds mit perror(3) (Funktion setzt errno ) oder fprintf(3) (sonst) (*);keine Fehlerausgabe bei selbst geschriebenen Bibliotheksfunktionen (z.B. der halde)! |
0,5 |
Behandlung des Fehlers: exit(3) oder return (**);kein exit bei selbst geschriebenen Bibliotheksfunktionen! |
0,5 |
Insgesamt wird für eine normale Fehlerbehandlung (Ausnahmen siehe unten) maximal 1 Punkt abgezogen, dies gilt auch wenn die Fehlerbehandlung komplett fehlt.
Falls die Fehlerbehandlung das Programm beendet, müssen keine Ressourcen (angeforderter Speicher, offene Dateien, etc.) freigegeben werden.
Ausnahmen und Ergänzungen
Fehlerbild | Punktabzug | Anmerkung |
---|---|---|
Fehlerbehandlung zu malloc(3) fehlt |
0,5 | |
Fehlerausgabe auf stdout |
0,5 | einmalig pro Abgabe |
Manche Funktionen benötigen aufwändigere Fehlerbehandlung, bei der das Prüfen auf einen Fehler komplizierter ist. Somit kann mehr als ein Punkt abgezogen werden. Der maximale Punktabzug pro Funktion ergibt sich aus der Summe der hier aufgezählten möglichen Fehler. Dieser wird auch verwendet, wenn die Fehlerbehandlung komplett fehlt.
-
strtol(3)
:Nötige Fehlerbehandlung Punktabzug errno
passend setzen sowie nach Aufruf prüfen0,5 endptr
prüfen (Eingabe nicht leer und wurde vollständig gelesen)0,5 Ausgabe und Behandlung wie oben (*) und (**) 1 -
fgets(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewert prüfen 0,5 Mit feof(3)
bzw.ferror(3)
auf Fehler prüfen0,5 Ausgabe und Behandlung wie oben (*) und (**) 1 -
fgetc(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewerte EOF
und0xFF
können unterschieden werden1 Prüfen des Rückgabewerts auf EOF
0,5 Mit feof(3)
bzw.ferror(3)
auf Fehler prüfen0,5 Ausgabe und Behandlung wie oben (*) und (**) 1 -
sysconf(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewert prüfen 0,5 Falls die angeforderte Information ein (Min-/Max-)Limit ist, passend errno
setzen und prüfen0,5 Ausgabe und Behandlung wie oben (*) und (**) 1 -
readdir(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewert prüfen 0,5 errno
passend vor jedem Aufruf setzen sowie nach Aufruf im Fehlerfall prüfen0,5 Ausgabe und Behandlung wie oben (*) und (**) 1 -
getcwd(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewert prüfen 0,5 errno
im Fehlerfall prüfen0,5 Falls errno
gleichERANGE
, ohne Abbruch Fehlergrund beseitigen und erneut aufrufen1 Ausgabe und Behandlung bei Fehler wie oben (*) und (**) 1 -
getaddrinfo(3)
:Nötige Fehlerbehandlung Punktabzug Rückgabewert prüfen 0,5 Ausgabe des Fehlergrunds mit perror(3)
(bei Rückgabe vonEAI_SYSTEM
) odergai_strerror(3)
(sonst)1 Behandlung bei Fehler wie oben (**) 0,5
Fehlerbehandlung bei Ein-/Ausgabe
Ein-/Ausgabe benötigt Fehlerbehandlung um beispielsweise Fehler beim Schreiben
auf eine volle Festplatte zu erkennen und damit Datenverlust zu verhindern.
Fehlerbehandlung ist für alle Funktionen nötig, die
Ein-/Ausgabe durchführen die zur Grundfunktionalität des Programms gehören
(geht aus der Aufgabe hervor). Das beinhaltet beispielsweise
printf(3)
, fclose(3)
oder close(2)
.
Ausgenommen davon sind dabei die Fehlermeldungen selbst sowie unwichtige
Ausgaben. Falls sich das Programm bei einem Schreibfehler sowieso mit einem
Fehlercode beenden würde (bspw. SIGPIPE
) so ist keine
Fehlerbehandlung nötig.
Damit auch Schreibfehler auf stdout
erkannt werden (wichtig falls
in eine Datei umgeleitet wird), muss vor Beendigung des Programms
stdout
mit fflush(3)
geflushed werden. Dies ist nur
nötig, falls das Programm Ausgaben auf stdout
nutzt.
Verbotene Funktionen
Folgende Funktionen ermöglichen keine korrekte Fehlerbehandlung und dürfen nicht verwendet werden. Als Punktabzug ergibt sich jeweils der maximale Punktabzug der korrekten Alternative.Verbotene Funktion | Alternative | Punktabzug |
---|---|---|
atoi(3) |
strtol(3) |
siehe oben bei strtol(3) |
Programmierfehler
Fehlerbild | Punktabzug |
---|---|
static fehlt |
0,5 |
Unnötige globale Variable | 0,5 |
free(3) fehlt |
1 |
close(2) oder fclose(3) fehlt |
1 |
printf(variable) , kein Format-String und variable vom Nutzer |
1 |
zu kleiner Puffer | 1 |
Verlust von benötigter Information durch Casten von Datentypen | 1 |
falsche Funktionsparameter | 0,5 |
errno wird vor perror(3) überschrieben (z.B. durch Funktionsaufruf) |
0,5 |
sonstige Programmierfehler (Folgefehler nur für dieselben Programmierfehler) | 1 |
Programmierstil (Fehler)
Fehlerbild | Punktabzug |
---|---|
Unnötig (deutlich zu) große Puffer | 0,5 |
goto , falls offensichtlich unnötig oder um Schleifen nachzubauen (Sprung nach oben) |
1 |
Ausgabe in Bibliotheksfunktionen (z.B. bei der halde) | 0,5 |
exit(3) in Bibliotheksfunktionen (z.B. bei der halde); abort(3) ist erlaubt wenn es die Angabe vorsieht |
1 |
offensichtlich schlechter Code (von Folgefehlern ausgenommen) | 1 |
Programmierstil (Hinweise)
Fehlerbild | Verbesserte Lösung |
---|---|
if (var) { free(var); } |
free(var); |
if (ptr == 0) { ... } |
if (ptr == NULL) { ... } |
(*ptr).member |
ptr->member |