[C/C++] read() unter UNIX auf file blockiert?

Dieses Thema im Forum "Programmierung & Entwicklung" wurde erstellt von myth2806, 20. November 2008 .

  1. 20. November 2008
    read() unter UNIX auf file blockiert?

    Hi,

    ich will einfach nur was aus einer Datei mit read() lesen aber das Programm blockiert bei dem Aufruf einfach.

    Logik:
    Code:
    char *buf;
    int f;
    
    buf = malloc(16);
    
    f = open("meinefile.bin", O_RDONLY);
    read(f, buf, 10);
    
    In der Datei stehen definitiv mindestens 20Byte oder so drinnen.
    Wieso funktioniert das nicht??

    btw: Ich will nicht mit fread arbeiten weil ich mir hiervon mehr performance erhoffe.

    greez myth
     
  2. 20. November 2008
    AW: read() unter UNIX auf file blockiert?

    Also C ist hoffentlich auch C unter Unix.

    open gibts meines Wissens nach nicht, ich kenn nur fopen und außerdem braucht du einen Filehandler. Ich glaub kaum, dass du einen Dateistrom einem int Wert zuweisen kannst.

    Code:
    
    FILE *datei;
    buf = malloc(16);
    
    datei=fopen("meinefile.bin", O_RDONLY);
    
    read(datei, buf, 10);
    
    fclose(datei);
    free(buf);
    
    mfg duddl
     
  3. 20. November 2008
    AW: read() unter UNIX auf file blockiert?

    ja doch das gibts. ist in unistd.h definiert. ich benutz das auch immer um von der stdin oder netzsockets zu lesen. da funktionierts tadellos.
    und unter unix gibt es halt keine dateizeiger sondern nur integerwerte über die auf streams zugegriffen werden kann.
     
  4. 20. November 2008
    AW: read() unter UNIX auf file blockiert?

    Ok, dann is das ein Fehler meinerseits Sry.

    mfg duddl
     
  5. 20. November 2008
    AW: read() unter UNIX auf file blockiert?

    Code:
    char *buf;
    int f;
    
    buf = malloc(16);
    
    f = open("meinefile.bin", O_RDONLY);
    read(f, buf, 10);
    
    du solltest dir mal den funktionsprototyp von read() angucken.
    da heißt es:
    ssize_t read ( int fd, void *buff, size_t bytenum)

    da siehst du das er als 2ten parameter einen pointer erwartet, also musst du ihm auch einen pointer auf dein buf geben.
    Richtig müsste deine read so aussehen:
    Code:
    read(f, &buf, 10);
    
    Das war's schon.

    [edit]
    grml, char *, jetzt bin ich verwirrt und raff gar nix mehr. Naja, wenn nicht geht kannst ja mal probieren über errno auf den Fehler zu schließen
    Code:
     if ( ( ret = read ( fd, buff, bytenum ) ) == -1)
     {
     fprintf( stderr," ERROR: Cannot read from file!\n");
     fprintf( stderr," ERROR Code: %d\t %s\n\n",errno, strerror(errno));
     exit(1);
     }
    
    dazu bruachst die headerdatei #include <errno.h>
     
  6. 21. November 2008
    AW: read() unter UNIX auf file blockiert?

    ja genau habe char * verwendet... sollte also ein pointer sein. habs auch mal mit "char buf[16]" ohne malloc versucht aber gleiches phänomen. er blockiert einfach beim aufruf von read. das ist auch der grund warum ich leider keinen fehler ausgeben kann

    greez myth
     
  7. 22. November 2008
    AW: read() unter UNIX auf file blockiert?

    mmh
    komisch, kann den fehler hier nicht reproduzieren. Die Datei die du ließt, ist angelegt, und du hast Leserechte nehm ich an.
    Vielleicht kannst du mit dem gnu debugger gdbg reinschauen.
    Dazu musst du deine Quellcodes mit der Zusaztoption -g complieren.
    'gcc -c -g quellcode.c bla.c yeih.c'
    Dann ganz normal mit '-o' linken.
    dann starten:

    'gdbg ./programmname'

    Nachdem du in dem Debugger drin bist, musst du dir einen Breakpoint setzen. Das geht ganz einfach mit dem Befehl:
    'break main' (das würde dir den break auf die main() setzen.)

    Von jetzt an, kannst du das Programm schritt für Schritt mit den Befehlen 'ni' und 'stepi' (next instruction und step into (trete in die funktion ein) ) das Programm durchgehen. Mit dem Befehl 'show variablenname' kannst du dir den inhalt von den Variablennamen ausgeben lassen, und zum Beispiel überprüfen ob der Filediskriptor in Ordnung ist.

    Den gdb in der Konsole ist zwar echt ätzend, aber hilft dir den Fehler vielleicht noch weiter einzugrenzen

    [edit]
    ach ja, und vielleicht solltest du noch "meinefile.bin" durch "./meinefile.bin"ersetzen. Damit der Kernel weiß in welchen Pfad er nach der Datei suchen muss ;-)
     
  8. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.