• Navigation überspringen
  • Zur Navigation
  • Zum Seitenende
Organisationsmenü öffnen Organisationsmenü schließen
Friedrich-Alexander-Universität Lehrstuhl für Informatik 4 (Systemsoftware)
  • FAUZur zentralen FAU Website
  1. Friedrich-Alexander-Universität
  2. Technische Fakultät
  3. Department Informatik
Suche öffnen
  • English
  • Campo
  • StudOn
  • FAUdir
  • Stellenangebote
  • Lageplan
  • Hilfe im Notfall
  1. Friedrich-Alexander-Universität
  2. Technische Fakultät
  3. Department Informatik
Friedrich-Alexander-Universität Lehrstuhl für Informatik 4 (Systemsoftware)
Menu Menu schließen
  • Lehrstuhl
    • Team
    • Aktuelles
    • Kontakt und Anfahrt
    • Leitbild
    • 50-jähriges Jubiläum
    Portal Lehrstuhl
  • Forschung
    • Forschungsbereiche
      • Betriebssysteme
      • Confidential Computing
      • Embedded Systems Software
      • Verteilte Systeme
    • Projekte
      • AIMBOS
      • BALu
      • BFT2Chain
      • DOSS
      • Mirador
      • NEON
      • PAVE
      • ResPECT
      • Watwa
    • Projektkampagnen
      • maRE
    • Seminar
      • Systemsoftware
    Portal Forschung
  • Publikationen
  • Lehre
    • Sommersemester 2025
      • Applied Software Architecture
      • Ausgewählte Kapitel der Systemsoftware
      • Betriebssystemtechnik
      • Projekt angewandte Systemsoftwaretechnik
      • System-Level Programming
      • Systemnahe Programmierung in C
      • Systemprogrammierung 1
      • Verteilte Systeme
    • Wintersemester 2025/26
      • Systemprogrammierung 2
      • Betriebssysteme
      • Middleware – Cloud Computing
      • Echtzeitsysteme
      • Virtuelle Maschinen
      • Web-basierte Systeme
      • Projekt angewandte Systemsoftwaretechnik
      • Aktuelle Entwicklung in Verteilten und Objektorientierten Betriebssystemen (für Bachelor-/Masterarbeit)
    Portal Lehre
  • Examensarbeiten
  1. Startseite
  2. Lehre
  3. Wintersemester 2025/26
  4. Systemprogrammierung 2
  5. Korrekturhinweise

Korrekturhinweise

Bereichsnavigation: Lehre
  • Systemprogrammierung 2
    • Vorlesung
      • # Termine
      • # Folien
    • Übung
      • # Informationen
      • # Termine
      • # Folien
      • # Aufgaben
    • Korrekturhinweise
      • Semesterplan
        • FAQ
          • Prüfungsinformationen
            • Altklausuren
              • Kontakt
                • Evaluation
                  • Intern

                  Korrekturhinweise

                  Korrekturhinweise

                  Die in den Aufgaben beschriebenen Anforderungen müssen durch das Programm erfüllt sein, damit Bonuspunkte gesammelt werden können. Im Folgenden wird erklärt, welche Anforderungen an Abgaben gestellt werden und wofür es Punkte bzw. Punktabzug gibt.

                  Die folgenden Ausführungen sind dabei als Richtlinien zu verstehen. Sie sind nicht notwendigerweise vollständig. In Ausnahmefällen kann davon abgewichen werden.

                  Ressourcenfreigabe

                  Zu Ressourcen gehören insbesondere Arbeitsspeicher und Dateideskriptoren. Alle angeforderten Ressourcen müssen vor Beendigung des Programms wieder freigegeben werden.
                  Ausnahme: Wird das Programm aufgrund eines Fehlers beendet, ist keine Ressourcenfreigabe nötig.

                  Fehlerbehandlung

                  Funktionen in C können oft fehlschlagen. Fehler müssen daher adäquat behandelt werden. Unterschiedliche Fehler erfordern unter Umständen unterschiedliche Fehlerbehandlung.

                  In der Regel erfordern alle Funktionen, die fehlschlagen können, eine Fehlerbehandlung. Ob und wann eine Funktion fehlschlagen kann, ist in der entsprechenden man-Page nachzulesen. Funktionen, die nur bei einer falschen Verwendung durch den Programmierer fehlschlagen können (z.B. sigaction(3p)), müssen nicht fehlerbehandelt werden.

                  Eine gute Fehlerbehandlung sollte folgende Elemente beinhalten:

                  1. Prüfen, ob und welcher Fehler aufgetreten ist:
                    Meist durch Auswerten des Rückgabewerts einer Funktion und / oder Auswerten der errno.
                    Achtung: Hiervon gibt es Ausnahmen.
                  2. Ausgabe einer Fehlermeldung:
                    Meist mit perror(3p) oder fprintf(3p). Die Ausgabe sollte auf der Standard-Fehlerausgabe (stderr) erfolgen.
                  3. Angemessene Reaktion auf den Fehler im Programm:
                    Bei Fehlern, die keine sinnvolle Fortsetzung des Programms mehr erlauben, sollte das Programm mit exit(3p) beendet werden. Andernfalls muss sichergestellt werden, dass das Programm normal weiterlaufen kann und kein unerwartetes Verhalten auftritt.

                  In Bibliotheksfunktionen ist die Fehlerbehandlung etwas anders. Hier darf weder eine direkte Ausgabe einer Fehlermeldung erfolgen noch das Programm beendet werden. Stattdessen muss der Benutzer der Funktion z.B. durch einen Rückgabewert von dem Fehler informiert werden.

                  Punktevergabe

                  Für jede abzugebende Datei ist auf dem Aufgabenblatt die maximal erreichbare Anzahl an Punkten angegeben. Für jeden gemachten Fehler werden Punkte von der Maximalpunktzahl abgezogen. Dazu gehören unter anderem:

                  • Fehlende oder falsche Funktionalität des Programms
                  • Fehlende Ressourcenfreigabe
                  • Mangelnde Fehlerbehandlung

                  Jede Datei wird mit mindestens 0 Punkten bewertet. Es können also keine Negativpunkte gesammelt werden. Außerdem gelten folgende Regeln:

                  • Falls nicht anders spezifiziert werden für jedes Auftreten eines Fehlers Punkte abgezogen.
                  • Auch mehrfacher Punktabzug für dieselbe Art von Fehler an unterschiedlichen Stellen im Programm ist möglich.
                  • Tritt dieselbe Art von Fehler mehrfach auf, so wird dieser ab dem dritten Auftreten als Folgefehler gewertet und es werden dafür keine Punkte mehr abgezogen.

                  Für das Arbeiten in Gruppen beliebiger Größe wird außerdem vom Abgabesystem automatisch ein zusätzlicher Bonuspunkt angerechnet.

                  Gängige Fehler

                  Im Folgenden werden einige häufig gemachten Fehler aufgeführt. Wir empfehlen das Programm vor der Abgabe auf diese Fehler hin zu überprüfen.

                  Wenn sich ein Programm nicht übersetzen lässt, werden von der jeweiligen Datei 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ösen eines Übersetzerfehlers >= 3

                  Für eine vollständig fehlende Fehlerbehandlung wird meistens nicht mehr als 1 Punkt abgezogen. Für Funktionen, die eine komplexere Fehlerbehandlung erfordern gibt es allerdings Ausnahmen.

                  Fehlerbild Punktabzug
                  Prüfen auf Fehler fehlt 0,5
                  errno wird zur Fehlerprüfung genutzt, obwohl dies laut Man-Page nicht vorgesehen ist 0,5
                  Keine Ausgabe einer Fehlermeldung mit perror(3p) oder fprintf(3p) 0,5
                  Ausgabe einer Fehlermeldung auf stdout statt auf stderr 0,5
                  Keine angemessene Reaktion auf den Fehler im Programm 0,5
                  Ausgabe einer Fehlermeldung in Bibliotheksfunktionen (z.B. in der halde) 0,5
                  Beenden des Programms in Bibliotheksfunktionen durch exit(3p) (z.B. in der halde); abort(3p) ist erlaubt, wenn es die Angabe vorsieht 1

                  Fehlerbehandlung ausgewählter Funktionen

                  Bestimmte Funktionen benötigen eine komplexere Fehlerbehandlung. Einige ausgewählte Funktionen werden hier mit der nötigen Fehlerbehandlung aufgelistet. Auch hierbei ist natürlich die Ausgabe einer Fehlermeldung sowie eine angemessene Reaktion auf den Fehler erforderlich. Die Liste erhebt keinen Anspruch auf Vollständigkeit.

                  Bei den Kriterien ist der entsprechende Punktabzug mit angegeben. Der maximale Punktabzug für diese Funktionen ist die Summe der angegebenen Abzüge + 1 Punkt für fehlende Ausgabe und Reaktion im Programm.

                  Nötige Fehlerbehandlung Punktabzug
                  strtol(3p)
                  errno vor dem Aufruf auf 0 setzen 0,5
                  Prüfen ob endptr auf das Ende der Zeichenkette zeigt
                  Damit wird sichergestellt, dass die Eingabe vollständig gelesen wurde.
                  0,5
                  fgets(3p)
                  Rückgabewert auf NULL prüfen 0,5
                  Mit feof(3p) bzw. ferror(3p) auf Fehler prüfen 0,5
                  fgetc(3p)
                  Rückgabewerte EOF und 0xFF können unterschieden werden 0,5
                  Prüfen des Rückgabewerts auf EOF 0,5
                  Mit feof(3p) bzw. ferror(3p) auf Fehler prüfen 0,5
                  sysconf(3p)
                  Rückgabewert prüfen 0,5
                  Falls die angeforderte Information ein (Min-/Max-)Limit ist, passend errno setzen und prüfen 0,5
                  readdir(3p)
                  Rückgabewert auf NULL prüfen 0,5
                  errno passend vor jedem Aufruf auf 0 setzen sowie nach Aufruf prüfen 0,5
                  getcwd(3p)
                  Rückgabewert auf NULL prüfen. 0,5
                  Im Fehlerfall errno überprüfen. 0,5
                  Falls errno gleich ERANGE, ohne Abbruch Fehlergrund beseitigen und erneut aufrufen 1
                  getaddrinfo(3p)
                  Zurückgegebenen Fehlercode prüfen 0,5
                  Ausgabe des Fehlergrunds.
                  Falls Fehlercode EAI_SYSTEM ist: Ausgabe mit perror(3p)
                  Ansonsten: Ausgabe mit gai_strerror(3p)
                  1

                  Grundsätzlich benötigen alle Funktionen zur Ein- und Ausgabe eine Fehlerbehandlung. Dies gilt auch für die Ausgabe auf stdout. In folgenden Fällen ist allerdings keine Fehlerbehandlung notwendig:

                  • Die Ausgabe gehört nicht zur Grundfunktionalität des Programms (unwichtige Ausgabe).
                  • Ausgabe von Fehlermeldungen
                  • Das Programm würde sich bei einem Ausgabefehler automatisch von selbst beenden (z.B. bei SIGPIPE).

                  Da Ausgaben (auch auf stdout) gepuffert werden, ist vor Beendigung des Programms ein Aufruf von fflush(3p) nötig.

                  Fehlerbild Punktabzug
                  free(3p) fehlt 1
                  close(3p) oder fclose(3p) fehlt 1
                  Unnötig (deutlich zu) große Puffer 0,5

                  Fehlerbild Anmerkung Punktabzug
                  .PHONY fehlt oder ist unvollständig 0,5
                  all (oder Entsprechung) ist nicht erstes Target 0,5
                  Abhängigkeit(en) fehlen pro Target 0,5
                  Auf der Webseite geforderte Compilerflags fehlen pro Compileraufruf 0,5
                  CFLAGS oder CC werden nicht genutzt pro Variable 0,5

                  Verbotene Funktion Alternative Punktabzug
                  atoi(3p) strtol(3p) siehe oben bei strtol(3p)

                  Fehlerbild Punktabzug
                  Unnötige globale Funktion (static fehlt) 0,5
                  Die Ausgabe einer Zeichenkette mit printf(3p) ohne Formatstring ist problematisch. Stammt die Zeichenkette vom Benutzer, stellt dies eine Sicherheitslücke dar.
                  Alternative: fprintf(3p) mit "%s" als Format-String.
                  1
                  Zu kleiner Puffer 1
                  Verlust von benötigter Information durch Casten von Datentypen 1
                  Falsche Funktionsparameter 0,5
                  Verwenden der errno, obwohl ihr Wert undefiniert ist.

                  Erklärung: Da errno eine globale Variable ist, kann diese von jeder Funktion verändert werden. Wird vor dem Auslesen der errno (z.B. durch perror(3p)) eine Funktion aufgerufen, die nicht explizit einen bestimmten Wert der errno gewährleistet, ist ihr Wert undefiniert.

                  0,5
                  Unbegrenzte Speicherallokation durch einen Benutzer möglich (DoS möglich).

                  Erklärung: Das Lesen von (potentiell) unbegrenzt vielen Zeichen aus einem Stream (z.B. stdin) kann dazu führen, dass der verfügbare Arbeitsspeicher vollläuft. Dies führt in der Regel zum Absturz des Programms.

                  2
                  Auslesen von uninitialisiertem Speicher 1
                  Zu spätes Freigeben von zuvor angefordertem Speicherplatz 0,5
                  Sonstige Programmierfehler 1

                  Fehlerbild Punktabzug
                  goto, falls offensichtlich unnötig oder um Schleifen nachzubauen (Sprung nach oben) 1
                  unnötiges Verwenden von Makros (pro Makro) 0,5
                  offensichtlich schlechter Code (von Folgefehlern ausgenommen) 1

                  Muster Verbesserte Lösung
                  if (ptr != NULL) free(ptr); free(var);
                  if (ptr == 0) if (ptr == NULL)
                  (*ptr).member ptr->member
                  Friedrich-Alexander-Universität
                  Erlangen-Nürnberg

                  Schlossplatz 4
                  91054 Erlangen
                  • Impressum
                  • Datenschutz
                  • Barrierefreiheit
                  • Facebook
                  • RSS Feed
                  • Xing
                  Nach oben