Torna indietro   Hardware Upgrade Forum > Software > Programmazione

iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
C'è tanta sostanza nel nuovo smartphone della Mela dedicato ai creator digitali. Nuovo telaio in alluminio, sistema di raffreddamento vapor chamber e tre fotocamere da 48 megapixel: non è un semplice smartphone, ma uno studio di produzione digitale on-the-go
Intel Panther Lake: i processori per i notebook del 2026
Intel Panther Lake: i processori per i notebook del 2026
Panther Lake è il nome in codice della prossima generazione di processori Intel Core Ultra, che vedremo al debutto da inizio 2026 nei notebook e nei sistemi desktop più compatti. Nuovi core, nuove GPU e soprattutto una struttura a tile che vede per la prima volta l'utilizzo della tecnologia produttiva Intel 18A: tanta potenza in più, ma senza perdere in efficienza
Intel Xeon 6+: è tempo di Clearwater Forest
Intel Xeon 6+: è tempo di Clearwater Forest
Intel ha annunciato la prossima generazione di processori Xeon dotati di E-Core, quelli per la massima efficienza energetica e densità di elaborazione. Grazie al processo produttivo Intel 18A, i core passano a un massimo di 288 per ogni socket, con aumento della potenza di calcolo e dell'efficienza complessiva.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 24-04-2007, 10:33   #1
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
[C] Problema lettura file binario! [risolto]

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.

Codice:
#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

Ultima modifica di chinchillart : 27-04-2007 alle 10:58.
chinchillart è offline   Rispondi citando il messaggio o parte di esso
Old 24-04-2007, 18:08   #2
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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.
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 24-04-2007, 18:41   #3
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
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
chinchillart è offline   Rispondi citando il messaggio o parte di esso
Old 24-04-2007, 20:18   #4
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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ù??

Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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:
Codice:
#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;
}
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 03:34   #5
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
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?)
__________________
In God we trust; all others bring data
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 10:28   #6
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
Quote:
Originariamente inviato da sottovento Guarda i messaggi
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:

Codice:
/* 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 è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 10:53   #7
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
Quote:
Originariamente inviato da sottovento Guarda i messaggi
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?

Roberto
chinchillart è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 11:00   #8
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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?
Ma scusa ... l'hai provato il mio sorgente? Fa vedere molto chiaramente quali sono le differenze nell'allineamento dei campi.
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 11:11   #9
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
Quote:
Originariamente inviato da andbin Guarda i messaggi
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.

Roberto
chinchillart è offline   Rispondi citando il messaggio o parte di esso
Old 25-04-2007, 11:18   #10
andbin
Senior Member
 
L'Avatar di andbin
 
Iscritto dal: Nov 2005
Città: TO
Messaggi: 5206
Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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!

Quote:
Originariamente inviato da chinchillart Guarda i messaggi
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> ad esempio.
__________________
Andrea, SCJP 5 (91%) - SCWCD 5 (94%)
andbin è offline   Rispondi citando il messaggio o parte di esso
Old 26-04-2007, 03:28   #11
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
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.
__________________
In God we trust; all others bring data

Ultima modifica di sottovento : 26-04-2007 alle 04:21. Motivo: nient'altro da fare
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 26-04-2007, 09:05   #12
chinchillart
Member
 
L'Avatar di chinchillart
 
Iscritto dal: Apr 2004
Città: Ravenna
Messaggi: 31
Quote:
Originariamente inviato da sottovento Guarda i messaggi
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...

Grazie mille!

Roberto
chinchillart è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile iPhone 17 Pro: più di uno smartphone. &Eg...
Intel Panther Lake: i processori per i notebook del 2026 Intel Panther Lake: i processori per i notebook ...
Intel Xeon 6+: è tempo di Clearwater Forest Intel Xeon 6+: è tempo di Clearwater Fore...
4K a 160Hz o Full HD a 320Hz? Titan Army P2712V, a un prezzo molto basso 4K a 160Hz o Full HD a 320Hz? Titan Army P2712V,...
Recensione Google Pixel Watch 4: basta sollevarlo e si ha Gemini sempre al polso Recensione Google Pixel Watch 4: basta sollevarl...
Le sonde spaziali ESA ExoMars e Mars Exp...
Roscosmos: static fire per i propulsori ...
Alcune partite NBA saranno trasmesse in ...
Intel Core 13000 e 14000 aumentano uffic...
Gemini sta per arrivare in Google Maps: ...
2 minuti per vedere le 27 offerte imperd...
Ray-Ban Meta Display: tecnologia sorpren...
Un mini PC a prezzo stracciato, non cerc...
Al via i coupon nascosti di ottobre: qua...
Ferrari Elettrica si aggiorna solo in of...
Doppio sconto sugli smartphone top Xiaom...
Samsung è sempre più prota...
ChatGPT ha pregiudizi politici? Ecco cos...
Un solo iPhone rubato ha portato alla sc...
Xiaomi 17 Ultra sta arrivando: ecco come...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 22:21.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v