Not logged in. · Lost password · Register

slukas
Member since Mar 2016
50 posts
Subject: 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.
This post was edited 2 times, last on 2019-06-23, 11:19 by slukas.
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
Quote by slukas on 2019-06-23, 10:55:
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?

Das steht dir frei. Allerdings ist es sinnvoller die erste errno zu returnen, damit der Aufrufer den ursprünglichen Fehlercode bekommt.

Quote by slukas on 2019-06-23, 10:55:
Und noch eine andere Frage: kann ich bei free() davon ausgehen, dass die errno nicht modifiziert wird?

Nein. Nur Funktionen die das expliziert dokumentieren können die errno nicht verändern.

Quote by slukas on 2019-06-23, 10:55:
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.

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.
slukas
Member since Mar 2016
50 posts
Danke.

    Zitat von slukas am 23.06.2019, 09:55:
    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.


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.
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.
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
Quote by slukas:
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 errno zu sichern). Aber worauf willst du dabei hinaus?
slukas
Member since Mar 2016
50 posts
Ja, wenn die Funktion einen Rückgabewert hätte, würde sie im Prinzip dasselbe tun (außer auch noch die errno zu sichern). Aber worauf willst du dabei hinaus?

Na du hast ja von einem Fehlerfall gesprochen:

Allerdings solltest du darauf achten im Fehlerfall so viel wie möglich freizugeben, also nicht gleich beim ersten Fehler abbrechen.

Den kann man im Code ja folglich weglassen.
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
Quote by slukas on 2019-06-25, 21:24:
Den kann man im Code ja folglich weglassen.

Verstehe gerade nicht, was du damit meinst.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Datenschutz | Kontakt
Powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2011 by Yves Goergen