Wie kann ich die Dateigröße einlesen

Dustbuster

Also bei MP3 Dateien hat es wunderbar funktioniert.

mady

Original erstellt von Dustbuster:
Also bei MP3 Dateien hat es wunderbar funktioniert.

Naja ... wenn Dein Compiler (und Standard-Bibliothek) das mitmacht und Du dein Programm nicht auf ein anderes System portierst, ist ja alles OK. Aber Du kannst nicht erwarten, dass fseek() automatisch immer funktioniert.

entelechie

warum ist bei binaeren dateien seek mit SEEK_END undefiniert.
ich hab das schon auf linux und windows mit verschiedenen
(teils auch nicht ganz aktuellen :)) compilern probiert
und hatte nie probleme damit.

mady

ISO/IEC 9899:1999, Kap. 7.19.3, Fußnote 225.

entelechie

hm, also es scheint wohl - auch wenn es im standard undefiniert
ist - auch fuer binaere dateien zu gelten.
ich habe ein bisschen rum-ge-googled und mir mal die ersten
10 - 15 seiten angeschaut; alle sagen, dass es mit seek_end moeglich
ist an das ende der datei zu springen, egal ob sie im binaeren oder
im text modus geoeffnet wurde.

HumeSikkins

@mady
Kannst du bitte mal posten was da steht? Ich habe nämlich nur den C99 Final Draft und da steht in Fußnote 225: "See ‘‘future library directions’’(7.26.9)."
Und das hilft einem nicht weiter

In C++ weiß ich, dass

ifstream in;
in.open(fileNane, ios::binary);
in.seekg(0, ios::end); // move to the end
unsigned long int fileSize = std::streamoff(in.tellg());
ifs.seekg(0, ios::beg); // go back to the beginning

korrekt ist für Dateien die mit dem C-locale und ios::binary geöffnet wurden.

Hätte also auch gedacht, dass dies für C ok ist.

SG1

In N869 ist es Fussnote 211:

Setting the file position indicator to end-of-file, as with fseek(file, 0, SEEK_END), has undefined behavior for a binary stream (because of possible trailing null characters) or for any stream with state-dependent encoding that does not assuredly end in the initial shift state.

Shade Of Mine

Original erstellt von entelechie:
ich habe ein bisschen rum-ge-googled und mir mal die ersten
10 - 15 seiten angeschaut; alle sagen, dass es mit seek_end moeglich
ist an das ende der datei zu springen, egal ob sie im binaeren oder
im text modus geoeffnet wurde.

Es ist egal was google sagt! Es zählt _nur_ was der Standard sagt!

HumeSikkins

@SG1
Danke fein

rüdiger

@entelchien
unter Linux kann dir das eh egal sein, da Unices keinen Binären Dateimodus kennen, da wird alles gleich behandelt (zum Glück!)

entelechie

Original erstellt von Shade Of Mine:
Es ist egal was google sagt! Es zählt _nur_ was der Standard sagt!

rofl

also ist ja schoen und gut was da (im Standard) steht...
nur wenn sich keiner daran haelt...
(kann ja ein gutes oder positives daran halten sein)
:p

Shade Of Mine

Original erstellt von entelechie:
**nur wenn sich keiner daran haelt...
**

Achja? Es haelt sich keiner daran? Die Programmierer halten sich nicht daran, deshalb ist es auch so schwer Programme zu portieren!

Ein SEEK_END ist unsicher, es kann dir mal um die Ohren fliegen, muss aber nicht!

Das selbe ist bei einem

char* p;
*p=3;

Es muss nichts passieren, aber es kann! Nur weil bei deinem Compiler dann nichts passiert, heisst es noch lange nicht, dass es bei einem anderen Compiler nicht anders sein kann.

SEEK_END haengt eben vom OS ab. Unter Windows und Unix wirst du keine Probleme haben, was aber wenn jemand mal dein Programm auf sein selbstgeschriebenes OS bringen will? Der arme Typ wird sich wundern warum nichts laeuft...

Naja, zugegeben bloedes Beispiel, aber dennoch... der Standard ist nicht zum Spass da, damit sich Leute wie du darueber lustig machen, sondern er ist sehr wichtig um die Plattformuabhaengigkeit von C zu erhalten!

entelechie

@shade:
hae?

ich hab mich nicht ueber den standard lustig gemacht.
ich halte es fuer sehr sinnvoll, dass es klare definitionen
fuer die sprache c gibt.

es ist aber auch zu sagen, wenn eine funktion fseek(..) gibt,
die sich einmal so und einmal so verhalten kann, dann ist das
schwachsinnig! das makro "seek_end" suggeriert, dass man sich
zum dateiende bewegt. ich bin immer davon ausgegagen, dass
es das auch tut.
ich halte diese definition fuer sehr schwammig.

mady

Original erstellt von entelechie:
...
es ist aber auch zu sagen, wenn eine funktion fseek(..) gibt,
die sich einmal so und einmal so verhalten kann, dann ist das
schwachsinnig! das makro "seek_end" suggeriert, dass man sich
zum dateiende bewegt. ich bin immer davon ausgegagen, dass
es das auch tut.
ich halte diese definition fuer sehr schwammig.

So stimmt das nicht! Der Standard gibt klare Regeln vor, wie fseek() zu verwenden ist. Weicht ein Programmierer vom Standard ab, dann verlässt er sich auf systemspezifische Dinge oder eben auf undefiniertes Verhalten.

Bashar

"The nice thing about standards is that there are so many to choose from." -- unbekannter Autor

Als da wären z.B. POSIX, worin fseek(x, SEEK_END) natürlich definiert ist.

mady

naja ... mir ging's um den aktuellen ISO-C Standard ... :))

entelechie

ich habe nie etwas anderes behauptet mady.

aber, fuer jemanden der den standard nicht so gut in
allen einzelheiten kennt (wie z.B. ich :)) ist ein
fseek( f, 0, SEEK_END ) sehr irrefuehrend.

mady

Original erstellt von entelechie:
**ich habe nie etwas anderes behauptet mady.

aber, fuer jemanden der den standard nicht so gut in
allen einzelheiten kennt (wie z.B. ich :)) ist ein
fseek( f, 0, SEEK_END ) sehr irrefuehrend.**

Da muss ich Dir recht geben. Ich selbst hab' den Befehl längere Zeit verwendet ....

Viele meiner (älteren) C-Bücher und Nachschlagewerke vermitteln die Sprache C 'am Standard vorbei'. Da sind z.T. falsche Formulierungen oder Sachverhalte nachzulesen. Schlechte Tut's (z.B. pronix.de) tun dann noch ihr übriges.

Schlechte Tut's (z.B. pronix.de) tun dann noch ihr übriges.

Kannst du das mal genauer erläutern. Was ist an diesem Tutorial so schlecht. Hab es vor einiger Zeit komplett durchgearbeitet und fand es total genial gemacht von der Aufmachung und den Informationen. Und jetzt erfahre ich das Tutorial sei schlecht?

int_esskar

BOOL GetFindData(LPSTR ss, WIN32_FIND_DATA *lpwinfd)
{
    WIN32_FIND_DATA w32ffd;
    HANDLE a;

    if (lpwinfd) memset(lpwinfd, 0, sizeof(WIN32_FIND_DATA));
    if ((a = FindFirstFile(ss, &w32ffd))!=INVALID_HANDLE_VALUE)
    {
        do
        {
            if (!(w32ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
            {
                FindClose(a);
                if (lpwinfd) memcpy(lpwinfd, &w32ffd, sizeof(WIN32_FIND_DATA));
                return TRUE;
            }
        } while (FindNextFile(a, &w32ffd));
        FindClose(a);
    }
    return FALSE;
}

DWORD GetFileSize(LPSTR ss)
{
    WIN32_FIND_DATA w32ffd;
    if (!GetFindData(ss, &w32ffd)) return 0;
    if (w32ffd.nFileSizeHigh) return 0xffffffff;
    return w32ffd.nFileSizeLow;
}