Verhalten von fcloseall und dessen Einsatzgebiet



  • @RBS2 sagte in Umgangston:

    Ich habe nichts dagegen, wenn man außergewöhnliche Lösungen entsprechend kommentiert. Ich find's nur doof, wenn man sich jegliches Denken abseits bewährter Patterns und Best Practices verbietet.

    Wenn du nicht verstehen kannst wieso sowas wie _fcloseall in einem Programm nichts zu suchen hat, dann ist dir vermutlich nicht mehr zu helfen. Grund: _fcloseall bricht Kapselung auf's übelste. Alle FILE* des Prozesses (ausgenommen die 3 Standardstreams) werden ungültig und beim nächsten Zugriff kracht's. Das "lösungsorientiert" zu nennen ist mMn. einfach nur beknackt.

    Wenn man keine Threads verwendet, keine dicken Frameworks, der eigene Code auch nicht viel ist und man nach _fcloseall quasi sofort exit oder besser _exit aufruft, dann mag es OK sein. Im Sinne von "korrekt". Schön ist es sicher nicht, und noch schlimmer: man läuft Gefahr sich damit etwas anzugewöhnen was in diesem einen Spezielfall gehen mag (weil halt die oben genannten Bedingungen zutreffen) aber im Allgemeinen nicht geht. Und man vermeidet damit zu lernen wie man es "ordentlich" macht.

    "Lösungsorientiert" wäre für mich maximal noch eine Lösung wo man in einem seltenen Fehlerfall einfach ne Fehlermeldung ausgibt und dann das Programm beendet. Ohne davor _fcloseall aufzurufen. Und idealerweise auch ohne Exit-Code laufen zu lassen, also mit _exit.



  • @hustbaer sagte in Umgangston:

    Wenn du nicht verstehen kannst wieso sowas wie _fcloseall in einem Programm nichts zu suchen hat, dann ist dir vermutlich nicht mehr zu helfen. Grund: _fcloseall bricht Kapselung auf's übelste. Alle FILE* des Prozesses (ausgenommen die 3 Standardstreams) werden ungültig und beim nächsten Zugriff kracht's. Das "lösungsorientiert" zu nennen ist mMn. einfach nur beknackt.

    Was heißt hier "nächster Zugriff"? Wer fcloseall aufruft, hat nicht vor einen nächsten Zugriff zu machen.



  • @hustbaer sagte in Umgangston:

    Nein, das hat mit lösungsorientiert nichts zu tun. An schlechtem Stil festzuhalten nur weil man es (noch) nicht anders kann und es in dem einen speziellen Fall den man gerade hat irgendwie hinzubiegen geht dass man es doch auf die krumme, unsaubere Tour machen kann ohne Probleme zu bekommen ist IMO nicht "lösungsorientiert" sondern einfach nur doof. Sturheit, Faulheit, Dummheit - irgendwas in der Richtung.

    Es gefällt dir nur nicht, hat aber mit Sturheit, Faulheit, Dummheit, nichts zu tun. Es hat damit zu tun:

    Sometimes we open multiple files for processing then it is tedious task to close all the open streams one by one after usage. C provides powerful feature to close all the open streams using single method.

    http://www.c4learn.com/c-programming/c-reference/fcloseall-function/

    Du musst das nicht mögen. Verlangt ja auch niemand von dir.



  • @hustbaer Lustig ist auch, daß sich POSIX und MS-crt mal wieder nicht einig sind, welche Streams geschlossen werden.



  • müssen sich posix und ms denn einig sein? also mal davon abgesehen, dass sich mir kein logischer grund einfällt, sowas wie fcloseall überhaupt aufzurufen, weil das betriebssystem (ja gut, da vielleicht) bei beendigung des programms ja sowieso alle datei schließt. aber entweder programmiere ich posix (#ifdef UNIX) oder windows (#ifdef WINDOWS) und die kleine unterscheidung sollte ich da dann doch hinkriegen, wenn es "portabel" sein soll, oder?



  • @Wade1234 sagte in Umgangston:

    müssen sich posix und ms denn einig sein?

    Hab' ich das gesagt?



  • hab ich halt so interpretiert. ich meine, wenn ich jemanden besuche und sage "hier stinkt es", dann heißt das im prinzip ja auch "lüfte mal", oder?



  • @Wade1234 sagte in Umgangston:

    müssen sich posix und ms denn einig sein?

    MS kocht öfter mal sein eigenes Süppchen, in der Hoffnung ein Alleinstellungsmerkmal zu schaffen. Das hat ihnen schon ein paar Mal Ärger eingebracht.

    also mal davon abgesehen, dass sich mir kein logischer grund einfällt, sowas wie fcloseall überhaupt aufzurufen, weil das betriebssystem (ja gut, da vielleicht) bei beendigung des programms ja sowieso alle datei schließt.

    Offenbar geht fcloseall() davon aus, dass nach dem Schließen der Handles das Programm noch weiter läuft. Man kann ja auch danach wieder neue FILE* öffnen.



  • @RBS2 sagte in Umgangston:

    MS kocht öfter mal sein eigenes Süppchen, in der Hoffnung ein Alleinstellungsmerkmal zu schaffen. Das hat ihnen schon ein paar Mal Ärger eingebracht.

    das ist ja im grunde auch deren gutes recht, oder?

    Offenbar geht fcloseall() davon aus, dass nach dem Schließen der Handles das Programm noch weiter läuft. Man kann ja auch danach wieder neue FILE* öffnen.

    ja aber irgendwie......... wie würde dir eine funktion freeall() gefallen? würdest du dir da nicht irgendwie an den kopf fassen und dich fragen, was der scheiß soll?



  • @Wade1234 sagte in Umgangston:

    das ist ja im grunde auch deren gutes recht, oder?

    Theoretisch schon, aber wegen ihrer Marktmacht finden manche US-Richter das nicht so toll.

    wie würde dir eine funktion freeall() gefallen? würdest du dir da nicht irgendwie an den kopf fassen und dich fragen, was der scheiß soll?

    Das wäre wie ein Heap-Reset. Sowas kann praktisch sein. Vor allem, weil man es an beliebigen Stellen aufrufen kann. So könnte man untergeordnete Routinen zum Abbruch zwingen, indem man sie gezielt in die Fehlerbehandlung zwingt.



  • Nur so nebenbei:

    GNU - fcloseall():

    This function should be used only in special situations, e.g., when an error occurred and the program must be aborted. Normally each single stream should be closed separately so that problems with individual streams can be identified. It is also problematic since the standard streams (see Standard Streams) will also be closed.

    Viel Spaß beim öffnen von stdin, stdout und stderr falls das Programm weiterlaufen soll.



  • @RBS2 sagte in Umgangston:

    Was heißt hier "nächster Zugriff"? Wer fcloseall aufruft, hat nicht vor einen nächsten Zugriff zu machen.

    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.

    Und das ist einfach Murks, weil es nicht nur irgendwelchen Best-Practices zuwiderläuft, sondern effektiv verhindert dass man auch nur irgendwo im gesamten Programm irgendwie "normal" programmieren kann.

    D.h. du kannst _fcloseall in vielen Programmen schonmal überhaupt nicht verwenden ohne üble Bugs damit zu schaffen. Und dort wo es (nocht) geht, beschneidest du damit massiv die Freiheit bei zukünftigen Erweiterungen/Anpassungen.

    Klar kann man jetzt sagen alles Ansichtssache und mir gefällt es einfach nur nicht. OK, ja, richtig. Mir gefallen Programme die sich schnell in einen unwartbaren verbuggten Haufen qualmender Scheisse verwandeln nicht. Ist aber nur subjektiv, kann man natürlich auch anders sehen. Nur ist man IMO dann halt doof.



  • @RBS2 sagte in Umgangston:

    Theoretisch schon, aber wegen ihrer Marktmacht finden manche US-Richter das nicht so toll.

    ich halte jetzt ehrlich gesagt nicht sonderlich viel von richtern, weil ihre entscheidung davon abhängt, was ihre freunde ihnen erzählen......

    Das wäre wie ein Heap-Reset. Sowas kann praktisch sein. Vor allem, weil man es an beliebigen Stellen aufrufen kann. So könnte man untergeordnete Routinen zum Abbruch zwingen, indem man sie gezielt in die Fehlerbehandlung zwingt.

    dann kann man auch, indem man ihnen mitteilt, dass sie abbrechen sollen.



  • @RBS2 sagte in Umgangston:

    Das wäre wie ein Heap-Reset. Sowas kann praktisch sein. Vor allem, weil man es an beliebigen Stellen aufrufen kann. So könnte man untergeordnete Routinen zum Abbruch zwingen, indem man sie gezielt in die Fehlerbehandlung zwingt.

    Ein Crash/Access-Violation/SIGSEGV ist für dich Fehlerbehandlung oder wie? Das ist doch echt nur mehr lächerlich.



  • @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.


Log in to reply