Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione vivo X300 Pro: è ancora lui il re della fotografia mobile, peccato per la batteria
Recensione vivo X300 Pro: è ancora lui il re della fotografia mobile, peccato per la batteria
vivo X300 Pro rappresenta un'evoluzione misurata della serie fotografica del produttore cinese, con un sistema di fotocamere migliorato, chipset Dimensity 9500 di ultima generazione e l'arrivo dell'interfaccia OriginOS 6 anche sui modelli internazionali. La scelta di limitare la batteria a 5.440mAh nel mercato europeo, rispetto ai 6.510mAh disponibili altrove, fa storcere un po' il naso
Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo
Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo
Lenovo Legion Go 2 è la nuova handheld PC gaming con processore AMD Ryzen Z2 Extreme (8 core Zen 5/5c, GPU RDNA 3.5 16 CU) e schermo OLED 8,8" 1920x1200 144Hz. È dotata anche di controller rimovibili TrueStrike con joystick Hall effect e una batteria da 74Wh. Rispetto al dispositivo che l'ha preceduta, migliora ergonomia e prestazioni a basse risoluzioni, ma pesa 920g e costa 1.299€ nella configurazione con 32GB RAM/1TB SSD e Z2 Extreme
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti
A re:Invent 2025, AWS mostra un’evoluzione profonda della propria strategia: l’IA diventa una piattaforma di servizi sempre più pronta all’uso, con agenti e modelli preconfigurati che accelerano lo sviluppo, mentre il cloud resta la base imprescindibile per governare dati, complessità e lock-in in uno scenario sempre più orientato all’hybrid cloud
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 24-04-2007, 11: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 11:58.
chinchillart è offline   Rispondi citando il messaggio o parte di esso
Old 24-04-2007, 19: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, 19: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, 21: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, 04: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, 11: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, 11: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, 12: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, 12: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, 12: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, 04: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 05:21. Motivo: nient'altro da fare
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 26-04-2007, 10: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


Recensione vivo X300 Pro: è ancora lui il re della fotografia mobile, peccato per la batteria Recensione vivo X300 Pro: è ancora lui il...
Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'' per spingere gli handheld gaming PC al massimo Lenovo Legion Go 2: Ryzen Z2 Extreme e OLED 8,8'...
AWS re:Invent 2025: inizia l'era dell'AI-as-a-Service con al centro gli agenti AWS re:Invent 2025: inizia l'era dell'AI-as-a-Se...
Cos'è la bolla dell'IA e perché se ne parla Cos'è la bolla dell'IA e perché se...
BOOX Palma 2 Pro in prova: l'e-reader diventa a colori, e davvero tascabile BOOX Palma 2 Pro in prova: l'e-reader diventa a ...
Crisi delle memorie: ASUS torna al passa...
Le console next-generation potrebbero es...
Gemini cresce ancora: la quota di mercat...
Samsung sfida TSMC: la capacità produtti...
Iliad alza il prezzo della fibra ottica ...
Il prossimo low cost di POCO sarà il più...
The Elder Scrolls VI: ecco le ultime sul...
Ecco i saldi di fine anno Amazon, 34 off...
iPhone Fold: scorte limitate al lancio m...
OpenAI porterà la pubblicità in ChatGPT ...
TSMC aumenterà ancora i prezzi: nel 2026...
Marvel pubblica anche il secondo teaser ...
Nuovo accordo tra xAI e il Pentagono: l'...
La famiglia Xiaomi 17 sta per registrare...
Nuove auto elettriche che vedremo sul me...
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: 16:27.


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