[C] Problema lettura file binario!

[chinchillart]

Ho uno strano problema che ho riscontrato tentando l'accesso diretto ad un file binario.

Problema: dato un file di record (definiti da una struct) si suppone che il record sia talmente grande da saturare il buffer ad ogni lettura. Quindi è richiesta una funzione che acceda in lettura ad un solo campo di ogni record del file.

Nell'esempio si vuole accedere al campo stringa interno al record.


#define STRLEN 80

struct record
{
int a,b,c; /* Campi prima della stringa */
float x;
char s[STRLEN];
float y; /* Campi dopo la stringa */
} RECORD;

void print_str_recfile(char *file_name)
{
int before_offset, after_offset; /* memorizzano gli offset dei dati prima e dopo stringa */
int k;
int seek_err;
int pos;
char str[STRLEN];
FILE *fp;

if ((fp = fopen(file_name, "rb")) == NULL)
{
printf("Errore apertura del file '%s'", file_name);
exit(1);
}
before_offset = 3*sizeof(int) + sizeof(float);
after_offset = sizeof(float);
clearerr(fp);
if (fseek(fp, before_offset, SEEK_SET) != 0)
{
printf("Errore di accesso al file '%s'", file_name);
fclose(fp);
exit(1);
}
else /* Esiste il primo record */
{
k = 0;
seek_err = FALSE;
while ((fread(str, 1, STRLEN, fp) > 0) && !seek_err)
{[INDENT]
printf("Record n. %d: %s\n", k, str);
k++;
pos = ftell(fp);
seek_err = fseek(fp, pos + after_offset + before_offset, SEEK_SET);
}
}
fclose(fp);
return;
}



Una volta generato il file, la funzione che legge e stampa il campo stringa mi dà un problema, inpratica stampa una stringa in più, naturalmente vuota.
Da un punto di vista logico la funzione sembra corretta, e non mi spiego questo problema.

Ho anche provato ad implementarla usando feof(), ma addirittura mi andava in loop infinito. Purtroppo il testo che sto leggendo tratta tutto in maniera superficiale, senza esempi.

Aiuto! :)

Roberto

[andbin]

Problema: dato un file di record (definiti da una struct) si suppone che il record sia talmente grande da saturare il buffer ad ogni lettura. Quindi è richiesta una funzione che acceda in lettura ad un solo campo di ogni record del file.Il tuo modo di determinare l'offset non va molto bene. La struttura infatti potrebbe avere internamente dei "padding". Se su file c'è la struttura scritta per intero (compresi eventuali padding), determinare l'offset sommando le dimensioni dei vari campi non va bene.
Visto che la struttura ha dimensioni davvero modeste (100 byte), leggi la struttura per intero, non singoli campi.
Comunque, in questo casi, è buona cosa specificare al compilatore di usare un allineamento di 1 byte per la struttura.

[chinchillart]

Allora, grazie mille per la veloce risposta.

L'ipotesi di lavoro è che la struttura sia molto grande, io ho solamente messo due-tre variabili per semplificare il caso reale.

Inoltre il programma (ed il file) non deve essere portabile, il file è generato e letto all'interno dello programma.

Non so cosa sia il "padding", ma deduco che siano organizzazione interne della struttura dipendente dal compilatore. Effettivamente ci avevo pensato, ma sul libro di testo che ho seguito non considerava questo problema.

Non ho capito assolutamente cosa vuol dire "specificare l'allineamento di un byte della struttura": mi devi scusare ma sono proprio alle prime armi. :)
Se puoi indirizzarmi su qualche "lettura" un pochino più tecnica e inerente al trattamento dei file (e allocazione della memoria) te ne sarei grato.

Roberto

[andbin]

L'ipotesi di lavoro è che la struttura sia molto grande, io ho solamente messo due-tre variabili per semplificare il caso reale.Ah ok. Comunque dovresti specificare meglio la reale dimensione, giusto per capire meglio la questione: 1000 byte? 10000 byte?? Molto di più??

Non so cosa sia il "padding", ma deduco che siano organizzazione interne della struttura dipendente dal compilatore. Effettivamente ci avevo pensato, ma sul libro di testo che ho seguito non considerava questo problema.

Non ho capito assolutamente cosa vuol dire "specificare l'allineamento di un byte della struttura": mi devi scusare ma sono proprio alle prime armi. :)
Se puoi indirizzarmi su qualche "lettura" un pochino più tecnica e inerente al trattamento dei file (e allocazione della memoria) te ne sarei grato.Fai prima a "vederlo" con i tuoi occhi. Non so che compilatore stai usando ma prova a compilare ed eseguire questo programmino:
#include <stdio.h>
#include <string.h>

#pragma pack(4)
typedef struct
{
char a;
int b;
short c;
} STRUCT_UNO;
#pragma pack()


#pragma pack(1)
typedef struct
{
char a;
int b;
short c;
} STRUCT_DUE;
#pragma pack()


void dump (void *ptr, int len)
{
char *p = (char*) ptr;
printf ("Len %3d ", len);
while (len-- > 0)
printf ("%02X ", *p++ & 0xFF);
printf ("\n");
}

int main (void)
{
STRUCT_UNO uno;
STRUCT_DUE due;

memset (&uno, 0, sizeof (uno));
memset (&due, 0, sizeof (due));

uno.a = due.a = 0x12;
uno.b = due.b = 0x11223344;
uno.c = due.c = 0x3456;

dump (&uno, sizeof (uno));
dump (&due, sizeof (due));

return 0;
}

[sottovento]

Quello che dice andbin e' corretto.
Comunque se stai usando un classico PC Intel non hai problemi di allineamento, in questo caso.
Fra l'altro, non hai problemi di allineamento nemmeno su un processore a 32 bit che allinei quale, per esempio, Motorola. La struttura che hai creato e' gia' perfettamente allineata.

Ho provato il tuo codice: funziona (ovviamente con le ipotesi di cui sopra).

Sei sicuro di aver scritto il file correttamente? Magari ti stampa una linea vuota perche' ce l'hai messa tu, nel file.... (per caso salvi anche il '\n' nella stringa?)

[chinchillart]

Quello che dice andbin e' corretto.
Comunque se stai usando un classico PC Intel non hai problemi di allineamento, in questo caso.
Fra l'altro, non hai problemi di allineamento nemmeno su un processore a 32 bit che allinei quale, per esempio, Motorola. La struttura che hai creato e' gia' perfettamente allineata.

Ho provato il tuo codice: funziona (ovviamente con le ipotesi di cui sopra).

Sei sicuro di aver scritto il file correttamente? Magari ti stampa una linea vuota perche' ce l'hai messa tu, nel file.... (per caso salvi anche il '\n' nella stringa?)

Ciao e grazie per l'intervento.
Il programma è compilato sotto Windows con Code::blocks e compilatore MiniGW. Su macchina Pentium.

Questo è il programma che acquisice i dati e scrive i record su file:


/* Acquisizione dei record dell'array */

int getrecarray(RECORD ra[], int max_rec_num)
{
int k;
RECORD r;
int terminate;

k = 0;
terminate = FALSE;
while (k < max_rec_num && !terminate)
{
r = *getrecord();
*(ra + k) = r;
k++;
printf("Continuare?\n");
terminate = !get_answer();
}
return (k + 1);
}

/* Scrittura del file */

int writerecarray(char *file_name, RECORD ra[], int max_rec_num)
{
int k;
FILE *fp;
RECORD *block;

if ((fp = fopen(file_name, "wb")) == NULL)
{
fclose(fp);
return (-1);
}
else
{
k = 0;
while (k < max_rec_num)
{
/* scrive un record alla volta, supponendo che
il record abbia dimensione >= buffer */
block = ra + k; /* oppure &ra[k] */
fwrite(block, sizeof(RECORD), 1, fp);
k++;
}
fclose(fp);
return 0;
}
}


int main(void)
{
int reccount;

reccount = getrecarray(recarray, MAXRECNUM);
if (writerecarray("test.dat", recarray, reccount))
{
printf("Errore scrittura file!\n");
exit(1);
}
return 0;
}

Mancano solo le funzioni get_answer(), che chiede yes/no, e la funzione getrecord() che restituisce un puntatore a RECORD.
Anche questo programma mi sembra formalmente corretto. Non capisco cosa non funzioni. :(

Se avete qualche suggerimento ve ne sarei grato.

Roberto

[chinchillart]

Quello che dice andbin e' corretto.
Comunque se stai usando un classico PC Intel non hai problemi di allineamento, in questo caso.
Fra l'altro, non hai problemi di allineamento nemmeno su un processore a 32 bit che allinei quale, per esempio, Motorola. La struttura che hai creato e' gia' perfettamente allineata.

Ho provato il tuo codice: funziona (ovviamente con le ipotesi di cui sopra).

Sei sicuro di aver scritto il file correttamente? Magari ti stampa una linea vuota perche' ce l'hai messa tu, nel file.... (per caso salvi anche il '\n' nella stringa?)

Aggiungo una domanda: la stuttura che ho creato segue l'allineamento standard o naturale, nel senso che l'indirizzo di memoria in cui è allocato il campo pippo è un multiplo della dimensione sizeof(pippo).
Ma se avessi ad esempio usato una stringa lunga 73 caratteri, anzichè 80, oppure inserito un campo char (1 byte), sarei uscito dall'allineamento standard e avrei avuto problemi nell'allocare le strutture leggendole dal file, vero?:confused:

Roberto

[andbin]

Aggiungo una domanda: la stuttura che ho creato segue l'allineamento standard o naturale, nel senso che l'indirizzo di memoria in cui è allocato il campo pippo è un multiplo della dimensione sizeof(pippo).
Ma se avessi ad esempio usato una stringa lunga 73 caratteri, anzichè 80, oppure inserito un campo char (1 byte), sarei uscito dall'allineamento standard e avrei avuto problemi nell'allocare le strutture leggendole dal file, vero?:confused:Ma scusa ... l'hai provato il mio sorgente? Fa vedere molto chiaramente quali sono le differenze nell'allineamento dei campi.

[chinchillart]

Ma scusa ... l'hai provato il mio sorgente? Fa vedere molto chiaramente quali sono le differenze nell'allineamento dei campi.

Sì sì il tuo sorgente l'ho provato ed è molto esplicativo. :)
Anche se non ho capito la funzione dump, di cui su cppreference.com non ho trovato nulla!

Mi pare di capire che la direttiva pack() modifica l'allineamento dei campi della struttura, ma sia su questa che su #pragma non ho sufficienti conoscenze.

Prima di risponderti volevo approfondire queste cose. :mc:

Roberto

[andbin]

Anche se non ho capito la funzione dump, di cui su cppreference.com non ho trovato nulla!L'ho fatta io quella funzione .... soltanto per mandare in output in esadecimale il contenuto della memoria!

Mi pare di capire che la direttiva pack() modifica l'allineamento dei campi della struttura, ma sia su questa che su #pragma non ho sufficienti conoscenze.Vedi <qui> (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas) ad esempio.

[sottovento]

Nella funzione getrecarray() ritorni (k+1): k e' sufficiente, lo post-incrementi. Questo significa che l'ultimo elemento che andrai a salvare (ammesso di non andare in crash) avra' contenuto indeterminato.

[chinchillart]

Nella funzione getrecarray() ritorni (k+1): k e' sufficiente, lo post-incrementi. Questo significa che l'ultimo elemento che andrai a salvare (ammesso di non andare in crash) avra' contenuto indeterminato.

Cacchio! E' vero! Salvo un elemento indeterminato su file!
Mi ero preoccupato della correttezza della funzione di lettura, e invece era sbagliata quella di scrittura... :muro:

Grazie mille! :)

Roberto