Warum verursacht fclose(NULL) von glibc einen Segmentierungsfehler, anstatt einen Fehler zurückzugeben?

Laut Manpage fclose(3):

RÜCKGABEWERT

Bei erfolgreichem Abschluss wird 0 zurückgegeben. Andernfalls, EOF zurückgegeben und die globale Variable errno gesetzt, um den Fehler anzuzeigen. In jedem Fall ist jeder weitere Zugriff (einschließlich eines weiteren Anrufs auf fclose()) an den Stream führt zu undefiniertem Verhalten.

FEHLER

EBADF Der zugrunde liegende Dateideskriptor fp ist ungültig.

Das fclose() Funktion kann auch fehlschlagen und eingestellt werden errno für alle Fehler, die für die Routinen angegeben sind close(2), write(2) oder fflush(3).

Na sicher fclose(NULL) sollte fehlschlagen, aber ich erwarte, dass es mit einem zurückkehrt errno normalerweise, anstatt direkt durch Segmentierungsfehler zu sterben. Gibt es einen Grund für dieses Verhalten?

Danke im Voraus.

UPDATE: Ich werde meinen Code hier einfügen (ich versuche es strerror()im Speziellen).

FILE *not_exist = NULL;

not_exist = fopen("nonexist", "r");
if(not_exist == NULL){
    printError(errno);
}

if(fclose(not_exist) == EOF){
    printError(errno);
}

fclose erfordert als Argument a FILE Zeiger erhalten entweder durch fopeneiner der Standardstreams stdin, stdoutoder stderr, oder auf eine andere implementierungsdefinierte Weise. Ein Nullzeiger gehört nicht dazu, daher ist das Verhalten undefiniert, genau wie fclose((FILE *)0xdeadbeef) wäre. NULL ist nichts Besonderes in C; Abgesehen von der Tatsache, dass es garantiert ungleich mit jedem gültigen Zeiger vergleicht, ist es genau wie jeder andere ungültige Zeiger, und seine Verwendung ruft ein undefiniertes Verhalten auf, außer wenn die Schnittstelle, die Sie es als Teil seines Vertrags an Dokumente übergeben, dies tut NULL hat eine besondere Bedeutung.

Außerdem wäre die Rückgabe mit einem Fehler gültig (da das Verhalten sowieso undefiniert ist), aber schädliches Verhalten für eine Implementierung, weil es verbirgt das undefinierte Verhalten. Das bevorzugte Ergebnis des Aufrufs von undefiniertem Verhalten ist immer ein Absturz, da es den Fehler hervorhebt und es Ihnen ermöglicht, ihn zu beheben. Die meisten Benutzer von fclose Suchen Sie nicht nach einem Fehlerrückgabewert, und ich würde wetten, dass die meisten Leute töricht genug sind, um zu bestehen NULL zu fclose werden nicht schlau genug sein, den Rückgabewert von zu überprüfen fclose. Man könnte argumentieren, dass Menschen sollte Überprüfen Sie den Rückgabewert von fclose in der Regel, da der letzte Flush fehlschlagen könnte, aber dies ist nicht notwendig für Dateien, die nur zum Lesen geöffnet werden, oder wenn fflush wurde vorher manuell aufgerufen fclose (Das ist sowieso eine klügere Redewendung, weil es einfacher ist, den Fehler zu behandeln, während Sie die Datei noch geöffnet haben).

fclose(NULL) sollte erfolgreich. free(NULL) erfolgreich ist, weil es dadurch einfacher wird, Bereinigungscode zu schreiben.

So wurde es leider nicht definiert. Daher können Sie nicht verwenden fclose(NULL) in portablen Programmen. (Siehe zB http://pubs.opengroup.org/onlinepubs/9699919799/).

Wie andere bereits erwähnt haben, möchten Sie im Allgemeinen keinen Fehler zurückgeben, wenn Sie NULL an die falsche Stelle übergeben. Sie möchten eine Warnmeldung, zumindest bei Debug-/Test-Builds. Die Dereferenzierung von NULL gibt Ihnen eine sofortige Warnmeldung und die Möglichkeit, einen Backtrace zu sammeln, der den Programmierfehler identifiziert :). Während Sie programmieren, ist ein Segfault der beste Fehler, den Sie bekommen können. C hat viel mehr subtile Fehler, deren Debugging viel länger dauert …

Es ist möglich, Fehlerrückgaben zu missbrauchen, um die Robustheit gegenüber Programmierfehlern zu erhöhen. Wenn Sie jedoch befürchten, dass ein Softwareabsturz Daten verlieren würde, beachten Sie, dass genau dasselbe passieren kann, zB wenn Ihre Hardware ausfällt. Deshalb haben wir Autosave (seit Unix-Texteditoren mit aus zwei Buchstaben bestehenden Namen wie ex und vi). Es wäre immer noch vorzuziehen, dass Ihre Software sichtbar abstürzt, anstatt mit einem inkonsistenten Zustand fortzufahren.

Die Fehler, von denen die Manpage spricht, sind Laufzeitfehler, keine Programmierfehler. Du kannst nicht einfach passieren NULL in jede API, die einen Zeiger erwartet, und erwarten, dass diese API etwas Vernünftiges tut. Vorbei an a NULL Zeiger auf eine Funktion, die dokumentiert ist, dass sie einen Zeiger auf Daten erfordert, ist ein Fehler.

Verwandte Frage: Soll ich in C oder C++ Zeigerparameter gegen NULL/nullptr prüfen?

Um den Kommentar von R. zu einer der Antworten auf diese Frage zu zitieren:

… Sie scheinen Fehler, die sich aus außergewöhnlichen Bedingungen in der Betriebsumgebung ergeben (FS voll, Speichermangel, Netzwerkausfall usw.), mit Programmierfehlern zu verwechseln. Im ersteren Fall muss natürlich ein robustes Programm in der Lage sein, sie elegant zu handhaben. Bei letzterem kann ein robustes Programm sie gar nicht erst erfahren.

Dies fclose() Das Problem scheint ein Erbe von FreeBSD zu sein und wurde sowohl vom Microsoft- als auch vom Linux-Lager unkritisch akzeptiert.

Aber HP, SGI, Solaris und CYGWIN hingegen beherrschen alle fclose(NULL) vernünftig. Zum Beispiel, man fclose für CYGWIN, das newlib anstelle der glibc des OP verwendet, heißt es:

fclose gibt bei Erfolg 0 zurück (auch wenn FP NULL ist oder keine geöffnete Datei)

Siehe https://stackoverflow.com/a/8442421/318716 für eine verwandte Diskussion.

Ich denke, die Manpage spricht über Underlying Dateideskriptor (diejenige, die von ihm intern über die erhalten wird open Systemaufruf, wenn Sie anrufen fopen) ungültig ist, nicht die Dateizeiger zu dem du übergehst fclose.