Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
SP2 jbuffer Modul sem.c
Hallo,
wir sollen ja im Fehlerfall die errno setzen bzw. gesetzt lassen und belegte Ressourcen freigeben.
Da ja das Freigeben der Ressourcen wiederum fehlschlagen kann und die errno dann möglicherweise neu gesetzt wird: Sollen wir den Fehlercode der ersten fehlgeschlagenen Funktion vor dem return in errno gespeichert haben und alle (neuen) Fehlercodes bei der Freigabe der Ressourcen ignorieren?
Und noch eine andere Frage: kann ich bei free() davon ausgehen, dass die errno nicht modifiziert wird?
Eine letzte Frage (vorerst :-p ): soll man bei der Methode semDestroy() jegliche fehlgeschlagenen Funktionen ignorieren? Wenn wir einfach returnen weiß ja der Aufrufer nicht ob die semDestroy() fehlgeschlagen ist außer er prüft das extra mit der errno, aber das ist ja nicht spezifiziert.
Das steht dir frei. Allerdings ist es sinnvoller die erste [m]errno[/m] zu returnen, damit der Aufrufer den ursprünglichen Fehlercode bekommt.
Nein. Nur Funktionen die das expliziert dokumentieren können die [m]errno[/m] nicht verändern.
Ja. Was anderes bleibt dir bei der vorgegebenen Methodensignatur auch nicht übrig. Allerdings solltest du darauf achten im Fehlerfall so viel wie möglich freizugeben, also nicht gleich beim ersten Fehler abbrechen. Der Aufrufer weiß nicht, ob das Freigeben erfolgreich war.
Danke.
Würde eine Fehlerbehandlung dann nicht genau das gleiche machen wie der normale Ablauf von semDestroy? also mutex oder cond destroyen (nachdem eine davon fehlgeschlagen ist) und anschließend sem freen. Einziger Unterschied wäre dann ja nur dass man am Ende die errno der ersten fehlgeschlagenen Funktion speichert.
Ja, wenn die Funktion einen Rückgabewert hätte, würde sie im Prinzip dasselbe tun (außer auch noch die [m]errno[/m] zu sichern). Aber worauf willst du dabei hinaus?
Na du hast ja von einem Fehlerfall gesprochen:
Den kann man im Code ja folglich weglassen.
Verstehe gerade nicht, was du damit meinst.