datei operationen



  • hi bin grad dabeiarbeit in c zu lernen und hab mir mal testweise nen kleines programm geschrieben.
    Ohne die Schleife und das FSEEK bekomm ichs hin das er mir das erste zeichen Binär anzeigt. Aber wenn ich versuche per FSEEK zu positionieren und die position jedes mal um 1 erhohlen will stürzt das Programm zur Laufzeit ab

    #include <stdio.h>
    #include <stdlib.h>
    
    int main()
    {
    
    	FILE *datei;
    	char zeichen;
    	int n;
    	n=1;
    
    	do{
    	fseek(datei,n,SEEK_SET);
        datei=fopen("test.txt","rb");
        fread(&zeichen, sizeof(char),1,datei);
    	printf("%c",zeichen);
        n++;
    	}while((fread(&zeichen, sizeof(char),1,datei)) != NULL);
    	fclose(datei);
    	return 0;
    
    }
    

    Datei enthält nur "Hallo", bekomme wie gesagt nur das h ausgegeben, wohl wieder irgend son dämlicher Fehler...

    PS: gibts ne möglichkeit auch direkt die ganze datei auszugeben?

    Schonmal danke für eure Hilfe ...



  • warum liest du nicht einfach Zeichen für Zeichen ein bis du auf '\0' stößt?



  • Hallo !

    Du hast da einmal fread zu viel drin.

    Gruß,
    p.



  • und wie kann ich das realisiren=?



  • fopen() in schleifen...
    calls in falscher reihenfolge...

    hast du einen schimmer, was du da tust?



  • So zum Bleistift:

    #include <stdio.h>
    
    main()
    {
    	char c;
    	FILE *fp = fopen("Blah.Blubb.dat", "r" );
    	while( ( c = fgetc( fp ) ) != EOF )
    		putch(c);
    	fclose(fp);
    }
    


  • kennste putchar?
    passt EOF in einen char?



  • Nach fclose(fp) würde ich aus REIN esthätischen Gründen auch noch clearerr() aufrufen bevor das Programm beendet wird, um den ERROR-INDIKATOR zu clearen! (fclose returnt EOF als Indikator)



  • Nach fclose ist der Stream geschlossen und freigegeben. Jedwege Aktion auf einem geschlossenen Stream ist undefiniert.



  • Da hast du recht, aber clearerr() ruft man ja auch nicht direkt mit dem stream auf sondern in Verwendung mit perror(). fclose besitzt halt einfach die Eigenschaft EOF als Indikator an perror zu übergeben, was man damit macht oder machen möchte, ist Geschmackssache.



  • c.rackwitz schrieb:

    kennste putchar?

    Ja, kenne ich, das ist der Zwillingsbruder von putch.
    Willsagen, int puchchar( int ) und int putch( int )
    sind bei mir quasi das selbe, weil mein Kompiler beide Funktionen kennt und beide Funktionen das gleiche Ergebnis bringen...jooooo. 🙂

    c.rackwitz schrieb:

    passt EOF in einen char?

    Ja, passt wie A. auf Eimer 🙂

    Siehe stdio.h:

    #define EOF     (-1)
    

    Und wie wird der Datentyp char intern repräsentiert ?
    Als (signed) int, genau !
    LG,
    p.



  • char ist 8 bit. intern sinds immernoch 8 bit.

    und was passiert, wenn ich rein zufaellig mehr als reines ascii ans stdin schicke, meinetwegen ein 0x80 ? dann hast du dein EOF

    ich kann C auch nicht leiden, aber deswegen die anfaenger fehlzuleiten ist schon mies



  • proggingmania schrieb:

    Und wie wird der Datentyp char intern repräsentiert ?
    Als (signed) int, genau !
    LG,
    p.

    Legst du einfach mal so fest...



  • c.rackwitz schrieb:

    und was passiert, wenn ich rein zufaellig mehr als reines ascii ans stdin schicke, meinetwegen ein 0x80 ? dann hast du dein EOF

    Kann ich dir sagen was passiert, dann gibt er das gleiche Zeichen aus, als wenn ich
    int i = 128;
    putch(i);
    schreibe, putzig nicht wahr ?

    c.rackwitz schrieb:

    ich kann C auch nicht leiden

    Also ich mag C ganz gern.

    c.rackwitz schrieb:

    aber deswegen die anfaenger fehlzuleiten ist schon mies

    Hört sich an als würd ich absichtlich falsche Tips geben,
    also, davon muss ich mich entschieden distanzieren.

    Tim schrieb:

    Legst du einfach mal so fest...

    Ich habe das in der Tat mal so gelernt, ok, war der Dozent nicht so prall
    mit der Schmach muss ich jetzt leben.

    Gruß,
    p.



  • c.rackwitz schrieb:

    und was passiert, wenn ich rein zufaellig mehr als reines ascii ans stdin schicke, meinetwegen ein 0x80 ? dann hast du dein EOF

    EOF ist '(int)-1', nicht '(char)-1'.
    jedenfalls darf EOF nicht in ein 'char' passen...

    [c.rackwitz schrieb:]
    ich kann C auch nicht leiden

    C ist spitze 👍



  • Wieso passt EOF nicht in char rein,
    das passt da wie A**** auf Eimer rein, aber hallo !
    So, in char gehen Zahlen von -128 bis +127 rein, das sind summa summarum
    128*EOF im negativen Bereich, gelle.
    Schreib doch mal char c = EOF;
    und dann kompilier das mal zusammen mit printf("%i", c );
    Meinst du da kommt ne Meldung von wegen Konstant too large oder so ? Neeee, der zeigt ganz brav -1 an, so wie sich das gehört.



  • Auch wenn ein Wert, welcher auf "(int)-1" lautet, bei der Konvertierung in signed char -1 bleibt, hast Du trotzdem unrecht, proggingmania.

    Der Grund ist ganz einfach: File-I/O-Funktionen, die ein int zurückliefern, lesen volle Bytes. Und da ein Byte und ein Char (welch Zufall) dieselbe Breite haben, bleibt hier kein Spielraum für EOF.

    Oder kannst Du plausibel erklären, warum zum Henker diese Funktionen int zurückgeben, und nicht einfach char, wenn doch EOF so toll in char definiert ist?



  • Theoretisch kann jeder Wert zwischen 0x00 und 0xFF (als signed char ist das 0..127;-128..-1) in deiner Datei vorkommen (und damit auch als Rückgabewert von getch() auftreten). Also kannst du nicht einfach einen Wert in diesem Bereich auswählen und als EOF festlegen. Darum gibt getch() auch einen int-Wert zurück, der entweder im Bereich 0..255 (echtes Zeichen) liegt oder EOF ist.
    Und mit deinen wirren Typumwandlungen erreichst du herzlich wenig - "char c=EOF" schneidet die letzten 8 Bit von -1 ab und bei der Ausgabe wird dieser Wert (der als signed char auch gleich -1 ist) wieder auf int-Länge erweitert. (auf einem System mit vorzeichenlosem 'char' würde der übrigens nicht -1 anzeigen, sondern 255 ;))



  • LordJaxom schrieb:

    ...
    Der Grund ist ganz einfach: File-I/O-Funktionen, die ein int zurückliefern, lesen volle Bytes. Und da ein Byte und ein Char (welch Zufall) dieselbe Breite haben, bleibt hier kein Spielraum für EOF.
    ...

    Eben, volle Bytes werden eingelesen. Wenn ich also Byteweise einlese, immer nur ein Byte, bis EOF kommt, wo soll dann der Platzmangel für EOF sein ?
    Dem armen kleinen EOF bleibt gar nichts anderes übrig, als in mein char c zu plumpsen und dort auch als solches erkannt zu werden.



  • ein scheiss troll, nix anderes.

    ich hab mir schon ein greasemonkey script gesucht um den spacken aus meinem blickfeld zu haben.


Anmelden zum Antworten