C: blokk olvasása fájlból

Letezo, fix meretu, mas altal epp' nem irt file-oknal nem kellene hogy gond legyen. Ott valami mas van a hatterben (a file egyszercsak elkezd nem letezni, valtozik a merete, mas is irja, stb).

Ugyanakkor ha debuggolnad a problemat, akkor ne `fread(buffer,N,1,fp)` modon, hanem `fread(buffer,1,N,fp)` modon olvasd be, es ugy nezd meg a visszateresi erteket. Ugy megkapod hogy hany byte-ot olvastal be, es nem azt hogy hany blokkot, es ez lehet hogy kozelebb visz a rejtely megoldasahoz. Illetve az is fontos az fread()-nal hogy: 

fread() does not distinguish between end-of-file and error, and callers must use feof(3) and ferror(3) to determine which occurred.

Szoval ha barmi gyanus, akkor ne brute-force modon fseek()-elj, hanem nezd meg hogy mi az oka. Egyeb hasznos fuggveny lehet meg az ftell() is. 

Tovabbi lehetosegek: `strace`-szel futtasd a programodat. Az nem mondja meg hogy magasszinten (stdio) mi a gond, de alacsonyszinen (unistd: open(), read(), stb) gyorsan valaszt kapsz arra hogyha valami rendszerszintu(bb) dolog miatt van fennakadas, vagy... vagy barmi egyeb. Szelsoseges esetben meg persze ilyesmik is lehetnek hogy disk i/o error vagy barmi megdurvabb. De ez a fent emlitett `strace`-szel, vagy siman `dmesg`-gel is kideritheto.

És mennyi, amikor nem 1? Ilyenkor ne találgass, hogy mi a baja, hanem kérdezd meg az ferror()-t meg az feof()-ot.

Egyébként a size is 1? Mert 1 byetonként olvasni egy fájlt nem túl hatékony.

Szvsz disk-file-okra nem hat, pipe/socket/chardev esetekre jó. Esetleg a topiknyitó kolléga text-módban olvas bináris fájlt? (WinDos-on)

Ah! Akkor itt van rogton egy gyanus dolog. Ha az int-ed ezen az architekturan az nem 2 byteos (ami elegge valoszinu, merthogy a 8 ill. 16 bites /most mar embedded/ rendszerek kivetelevel mindenhol 4 byte-os), akkor az int-ed aslo ket byte-jat fogja csak felulirni ez az `fread( &address, 2, 1, src );` utasitas. Sot, az eredmeny az MSB-LSB fuggo is, bar valoszinusithetoen LSB-s architekturan dolgozol.

A helyes megoldas ez lenne:

#include <stdint.h>
int16_t address;
fread( &address, 2, 1, src );

Ettol fuggetlenul jo lenne latni a teljes kodot, hatha van benne mas hasonlo turpissag is. 

O.K. NE keverd a fgetc()-t és az fread()-et! Lehet, hogy az fget()-c dob egy file végét, ha a binárisban filevége karakter van (asszem ASCII26, ^Z)!

Ha jól sejtem az olvasással egyben fel is szeleteled a fájl bizonyos logika szerint. Olvass be egy nagyobb puffert és abban kotorássz. A feldolgozás is gyorsabb lesz (egyébként is beolvasódik egy BUFFSIZE méretű blokk!). Az fread egy nagyon stabil utasítás, eddig SOHA nem tapasztaltam olyasmit, amit leírtál.

Én így csinálnám:

--------------------

#define MAX_BUFFER 256

unsigned char my_buffer[MAX_BUFFER];

FILE *fp;

unsigned int num_of_byte;

fp=fopen(file_name,"rb");

while(!feof(fp))

{

  num_of_byte= fread(my_buffer,1,MAX_BUFFER,fp);

  feldolgozás(num_of_byte, egyéb_paraméterek....,);

}

fflush(fp);fclos(fp);

// kérem az fflush megköpködésének mellőzését!

Igen, ilyen nincs altalanos lib-kent, mert ez mar nagyon alkalmazas-fuggo.

Egyreszt azert mert konkret fizikailag letezo, file-szeru objektumoknal (azaz filerendszerbeli fileoknal, meg unix-rendszerek alatt block device-eknel) nem jelenik meg a problema egyatalan. Azaz ezeknel ha nem annyit tudsz kiolvasni amennyit szeretnel csak kevesebbet akkor es csak akkor van vege a file-nak. Abban az esetben mikor az altalad megnyitot file vegere ertel, nyitva maradt, de valaki menet kozben, utolag ir hozza meg egy kicsit es ujra folytatni akarod az olvasast azt persze lehet, amint megkapod azt az infot hogy "jaj, megiscsak nott a file-om menetkozben". De ez mar tulmutat a klasszik libc/stdio keretein belul, lasd: `man 7 inotify`, `man 1 inotifywait`, stb. A hetkoznapi eletben ez a `tail -f ...` parancs implementacional jon szembe: azt sem lehetne mar klasszik stdio-val megoldani.

Abban az esetben viszont amikor varnal adatot, de nem jon epp annyi, de azert megis bevarnad mig megerkezik (azaz pipe-ok, socket-ek, chardev-ek olvasasa) az mar szintugy nem annyira klasszik stdio-hataskor. De valojaban kezelheto lehet stdio-val is, ha kelloen specialis az alkalmazas. Beagyazott rendszereknel, amikor fopencookie()-val csinalunk stdio-absztrakciot pl egy UART fole, akkor ezek hasznosak lehetnek. De ezeken felul pl pipe/socket IPC-knel egy sajat hread() fv-t hasznalok erre a celra egyszerubb esetekben, ami kb igy fest:

ssize_t hread(int fd,void *vbuff,size_t len)
{
 unsigned char  *buff;
 ssize_t        r0,r;

 r0=0;
 buff=(unsigned char *)vbuff;
 while ( 0<len )
  {     r=read(fd,buff,len);
        if ( r<0 )              return(r);
        else if ( r==0 )        return(r0);
        r0+=r;
        buff+=r;
        len-=r;
  };

 return(r0);
}

Ez pont azt csinalja amire gondolunk: azaz csak akkor ter vissza ha tenylegesen megjott a kert adatmennyiseg, vagy valami fennakadas volt menetkozben (pl vege a stream-nek, lezartak a pipe-t, socket-et, valamelyik hibat dobott). Egyszerubb esetekben - pl UNIX domain socket-eknel - ez teljesen jo es biztonsagosnak mondhato, de kicsit instabilabb kornyezetben (chardev-ek vilagaban, vagy magaban a nagybetus interwebek vilagaban) magaban hordozza azt a kockazatot hogy blokkol ha valami miatt megsem jon adat. Szoval ilyesmire gondol a kolto amikor aszondja hogy "nagyon alkalmazas-fuggo".

Mivel nem tudom mlyen operációs rendszert használsz, azt kell mondanom, hogy fogalmam sincsen. Normálisabb operációs rendszereken és filerendszereknél a kilépés után a kernel felszabadítja az erőforásokat és lezárja a nyiotott fileokat. Linuxnál, sem az r, sem ar rb-vel megnyitott file nem marad nyitva az alkalmazás kilépése után.

detto :]

Ja, ja, van, aki még öregebb.

Ez nem a veszett fejsze nyele, hanem egy akna.