Zum Verstehen: fclose() Unterschied DLL und Konsole

pointercrash**

Werte Forumsbesucher,

bei so einer Multiplattformgeschichte mit einer Latte include Guards bin ich über einen komischen Unterschied gestolpert:
Ich öffne zwei Dateinamen und prüfe:

if (!(infile && outfile))
	{
		fclose(infile);
		fclose(outfile);
		return -1;
	}

Ist eine der Dateien unter der Konsolenversion nicht zu öffnen, kommt das Ding mit -1 zurück und beendet sich. Gut soweit, es wurde aber (erfolgreich) versucht, eine NULL zu closen. Weiter passiert nix.
Wird es als DLL compiliert und geladen, geht es übern Jordan und nimmt den aufrufenden Prozess mit ins Grab. Mit ein paar Zeilen plus ist das Problem keins mehr, aber kapiert hätte ich das schon gerne, warum das so ist.

Inner Konsole kein Problen, als DLL sehr wohl

Basher_ist_nicht_BashAr

^^die dazugehörigen fopens passieren auch in der DLL?
falls nicht: dll und hostprozess könnten zwei verschiedene sätze von FILE*-funktionen haben, d.h. du solltest FILE-pointers besser nicht zwischen beiden herumreichen.

pointercrash**

Basher schrieb:

^^die dazugehörigen fopens passieren auch in der DLL?
falls nicht: dll und hostprozess könnten zwei verschiedene sätze von FILE*-funktionen haben, d.h. du solltest FILE-pointers besser nicht zwischen beiden herumreichen.

Tu' ich nicht. Von der aufrufenden main() bzw. dem Prozess kommen nur Filenames (char *), also die Dateinamen.
Unterm Strich waren es fclose(NULL), die das Teil als DLL zur Strecke gebracht haben, in der Konsole hat das keine Rolle gespielt.
Es ist eher eine akademische Frage, weil ich seit der Umstellung auf

if (infile)
		{
			fclose(infile);
			infile = NULL;
		}

auch keine Probleme mehr habe. Liegts am Compiler, am Luftdruck, keine Ahhung, wissen möchte ich es dennoch, weil ich nicht so auf Vodoo- Zeugs stehe ...

Basher_ist_nicht_BashAr

pointercrash() schrieb:

Es ist eher eine akademische Frage, weil ich seit der Umstellung auf
if (infile)
		{
			fclose(infile);
			infile = NULL;
		}
auch keine Probleme mehr habe.

dann wird der code wohl mehmals ausgeführt, obwohl er nur einmal sollte. mach mal eine messagebox rein und zähl mit, wie oft du auf 'ok' klickern musst.

Martin Richter

Was für einen Compiler/CRT verwendest Du?
Die MS-CRT sichert die Verwednung von fclose(NULL) ab. Es kann also nicht zu einem Crash kommen.
Schau einfach in den Sourcecode der CRT!

int __cdecl fclose (
        FILE *stream
        )
{
        int result = EOF;

        _VALIDATE_RETURN((stream != NULL), EINVAL, EOF);

        /* If stream is a string, simply clear flag and return EOF */
        if (stream->_flag & _IOSTRG)
                stream->_flag = 0;  /* IS THIS REALLY NEEDED ??? */

        /* Stream is a real file. */
        else {
                _lock_str(stream);
                __try {
                        result = _fclose_nolock(stream);
                }
                __finally {
                        _unlock_str(stream);
                }
        }

        return(result);
}

pointercrash**

Basher schrieb:

dann wird der code wohl mehmals ausgeführt, obwohl er nur einmal sollte. mach mal eine messagebox rein und zähl mit, wie oft du auf 'ok' klickern musst.

Exakt ein mal - das kann's dann nicht sein. Über Messageboxes hab' ich ja erst rausbekommen, wo's kracht.

Martin Richter schrieb:

Was für einen Compiler/CRT verwendest Du?
Die MS-CRT sichert die Verwednung von fclose(NULL) ab. Es kann also nicht zu einem Crash kommen.
Schau einfach in den Sourcecode der CRT!...

Bei mir spielt die 6er Pelles C. Kann es daran liegen? Werd' da auch mal die Source von fclose suchen.

Also passiert ist das so:
Ich schaufel' Daten über ein paar Berechnungsstufen von infile nach outfile. Durch einen falsch gesetzten include guard (pure Schlamperei!) ist für die Win- Versionen (Konsole/DLL) von der vorherigen Stufe eine Ausgabe- Datei offen stehen geblieben, die in der nächsten Stufe als Eingabedatei geöffnet werden sollte. Als DLL gab's dann eine access violation.
Ich werd' die DLL heute noch mit ein paar künstlich provozierten Fehlern konfrontieren, wenn sie dann wie gewünscht reagiert, geb' ich's zur Akte X ...