Verhalten von fcloseall und dessen Einsatzgebiet
-
@hustbaer sagte in Umgangston:
Und genau das ist das Problem: _fcloseall macht es unmöglich unabhängige "Programmteile" (Objekte, Module, was auch immer) zu haben, die File-Streams "besitzen" (ownership). Zumindest so lange diese nicht speziell auf den Aufruf von _fcloseall angepasst wurden und ggf. vor dem _fcloseall Aufruf darüber informiert werden dass ihre File-Streams jetzt gleich sterben werden.
Besitz eines File-Streams ist eh eine Illusion. Du kannst ihn dir vom OS borgen, aber wenn z.B. mit dem Medium selbst etwas faul ist, ist der Stream keinen Pfifferling mehr wert.
So gesehen ließe sich fcloseall() doch prima zum Testen einsetzen, also ob dein Code korrekt auf fehlgeschlagenes File-I/O reagiert.
-
@hustbaer Ich würd ja aufgeben
//edit: Vor allem ist das ganze gequatsche hier OT und sollte abgetrennt oder entsorgt werden.
-
@hustbaer sagte in Umgangston:
Ein Crash/Access-Violation/SIGSEGV ist für dich Fehlerbehandlung oder wie?
Idealerweise löst das OS dann eine Exception aus, die man im Usermode abfangen kann. IMHO macht Windows das. Was Unixe dazu sagen, weiß ich aber nicht.
-
@RBS2 sagte in Umgangston:
So gesehen ließe sich fcloseall() doch prima zum Testen einsetzen, also ob dein Code korrekt auf fehlgeschlagenes File-I/O reagiert.
#ifdef DEBUG
fclose(myfile);
#endif@Swordfish sagte in Umgangston:
@hustbaer Ich würd ja aufgeben
aufgeben ist was für versager!
-
@Wade1234 sagte in Umgangston:
aufgeben ist was für versager!
Für den lieben Swordfisch ist das hier wohl sowas wie ein Ringkampf, aber kein lockeres Gespräch.
-
@RBS2 sagte in Umgangston:
So gesehen ließe sich fcloseall() doch prima zum Testen einsetzen, also ob dein Code korrekt auf fehlgeschlagenes File-I/O reagiert.
Nein, würde es nicht, weil es CRASHT wenn man die ungültig gewordenen Stream-Pointer danach noch verwendet.
Idealerweise löst das OS dann eine Exception aus, die man im Usermode abfangen kann. IMHO macht Windows das. Was Unixe dazu sagen, weiß ich aber nicht.
Ja sicher tut es das. Und ja sicher gibt's da auf POSIX Systemen auch was. Nur ist das was passiert wenn man eine File Funktion auf einen ungültig gewordenen Stream-Pointer aufruft leider nicht garantiert eine Access-Violation sondern schlicht und ergreifend undefined behavior. Und damit EIN FEHLER, ganz egal was man für Handler registriert hat.
Ernsthaft jetzt, du hast ganz offensichtlich überhaupt genau gar keinen Plan von was du da gerade redest.
-
@RBS2 Aufgeben mit dir über irgendetwas zu diskutieren. Du hast sowieso deine Meinung die du mit "Argumenten" verteidigst andererseits aber wirklichen Argumenten anderer null-komma-nix zugänglich bist. Macht keinen Spaß. Hat keinen Sinn. Next.
-
@hustbaer sagte in Umgangston:
Nein, würde es nicht, weil es CRASHT wenn man die ungültig gewordenen Stream-Pointer danach noch verwendet.
Was auch passiert, wenn z.B. dein Speicherstick voll wird, den deine Anwendung gerade beschreibt. Mit diesem Zustand sollte jedes gute Programm umzugehen wissen. Und den kann man z.B. mit einem unverhofften fcloseall() simulieren.
Ernsthaft jetzt, du hast ganz offensichtlich überhaupt genau gar keinen Plan von was du da gerade redest.
Ich habe fcloseall() nie selbst angewendet, aber ich gehe mal davon aus, dass ich mit meinen Vermutungen hier nicht ganz falsch liege.
-
@RBS2 sagte in Umgangston:
Was auch passiert, wenn z.B. dein Speicherstick voll wird, den deine Anwendung gerade beschreibt. Mit diesem Zustand sollte jedes gute Programm umzugehen wissen. Und den kann man z.B. mit einem unverhofften fcloseall() simulieren.
Nein, kann man nicht. Dann schlägt eine Schreiboperation fehl. Das heißt nicht, daß einem der Stream plötzlich unterm Arsch weggezogen wird.
-
@RBS2 sagte in Umgangston:
Für den lieben Swordfisch ist das hier wohl sowas wie ein Ringkampf, aber kein lockeres Gespräch.
deshalb habe ich ja versucht, ihn zum durchhalten zu ermutigen..........
trotzdem: beim testen löst man einen einzigen fehler aus, guckt ob die fehlerbehandlung greift und behebt den fehler dann wieder. man schießt da nicht das halbe programm dafür ab.
@RBS2 sagte in Umgangston:
Was auch passiert, wenn z.B. dein Speicherstick voll wird, den deine Anwendung gerade beschreibt. Mit diesem Zustand sollte jedes gute Programm umzugehen wissen. Und den kann man z.B. mit einem unverhofften fcloseall() simulieren.
also ich habs jetzt nicht nachgeguckt, aber ich meine, dass du dann end of file bekommst und nicht invalid handle.
Ich habe fcloseall() nie selbst angewendet, aber ich gehe mal davon aus, dass ich mit meinen Vermutungen hier nicht ganz falsch liege.
deshalb erzählen wir dir ja, dass man kein fcloseall zum testen verwendet. zur not schreibst du den speicherstick halt vorher voll.
-
@RBS2 Ernst gemeinte Frage: Weisst du was der Unterschied zwischen einem CRASH und der kontrollierten Rückgabe eines Fehlercodes ist?
-
@Swordfish sagte in Umgangston:
Nein, kann man nicht. Dann schlägt eine Schreiboperation fehl. Das heißt nicht, daß einem der Stream plötzlich unterm Arsch weggezogen wird.
Das gilt es auszuprobieren. Ich behaupte, dass nach einem fcloseall() ein Schreibzugriff fehlschlägt, nicht aber das Programm abstürzt. Vielleicht hat ja jemand Bock das zu testen. Ich mache das morgen mal.
-
@Wade1234 sagte in Umgangston:
also ich habs jetzt nicht nachgeguckt, aber ich meine, dass du dann end of file bekommst und nicht invalid handle.
Invalid handle wäre ja noch toll.
_fcloseallmacht aber sämtlicheFILE*ungültig. Also nicht dass das Objekt dahiner als "ich bin jetzt zu" markiert wird, sondern alleFILEZeiger sind danach ungültig. Also nix mit "invalid handle" sondern KABOOM!
-
@RBS2 sagte in Umgangston:
Das gilt es auszuprobieren.
Da braucht man nichts auszuprobieren. RTFM reicht.
@RBS2 sagte in Umgangston:
Dann schlägt eine Schreiboperation fehl.
bezog sich auf "Was auch passiert, wenn z.B. dein Speicherstick voll wird".
-
@RBS2 sagte in Umgangston:
Das gilt es auszuprobieren. Ich behaupte, dass nach einem fcloseall() ein Schreibzugriff fehlschlägt, nicht aber das Programm abstürzt. Vielleicht hat ja jemand Bock das zu testen. Ich mache das morgen mal.
Ich habe es ausprobiert, und zwar bevor ich anfing hier heute eine etwas derbere Ausdrucksweise zu verwenden. Weil ich mir nur 99% sicher war aber nicht 100%. Auf Windows, Visual Studio 2017. ES CRASHT. Access-Violation.
Alter Schwede
-
@hustbaer sagte in Umgangston:
etwas derbere Ausdrucksweise zu verwenden.witzig, dass wir hier in einem thread, der davon handelt, dass der umgangston schlecht ist, irgendwas ausdiskutieren und der umgangston dabei schlecht ist.
-
-
@hustbaer sagte in Umgangston:
Ich habe es ausprobiert, und zwar bevor ich anfing hier heute eine etwas derbere Ausdrucksweise zu verwenden. Weil ich mir nur 99% sicher war aber nicht 100%. Auf Windows, Visual Studio 2017. ES CRASHT. Access-Violation.
Danke für die Info. Ich werde versuchen, mit etwa den gleichen Voraussetzungen den Crash zu reproduzieren.
-
@Wade1234 sagte in Umgangston:
witzig, dass wir hier in einem thread, der davon handelt, dass der umgangston schlecht ist, irgendwas ausdiskutieren und der umgangston dabei schlecht ist.
Was lernen wir daraus? Also trotz allen Gepöbels immer cool bleiben. Guter Thread!
-
@Wade1234 sagte in Umgangston:
also ich habs jetzt nicht nachgeguckt, aber ich meine, dass du dann end of file bekommst und nicht invalid handle.
Was letztlich egal ist. Die Frage ist "Fehlercode oder Absturz". Husti sagt, das Programm nippelt ab.
