Newsgroup: it.comp.lang.c
Titolo: FILE data type

Salve, supponiamo che io dichiari un dato FILE e lo inizializzi mediante la 
funzione fopen(...) come segue
FILE *pippo;
pippo = fopen("myfile","r");
vorrei sapere esattamente cosa succede come stream;
Io credevo che venissero copiati i bit del file attraverso uno stream in un 
buffer di memoria, cui pippo andrebbe a puntare... č corretto?
Con la mia IDE posso simulare una CPU e visualizzare registri e memoria; mi 
chiedevo se una volta eseguito il comando fopen fossero bisibili i byte del 
file "myfile" dentro la memoria..
____________________
Se la so, rispondo sempre. 

 file "myfile" dentro la memoria..
Nope.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 file "myfile" dentro la memoria..
Stai parlando di un debugger? In teoria quello che chiedi si potrebbe fare
con un debugger, ma anche lo stdio deve essere stato compilato con le
opzioni di debug. Infatti hai bisogno di eseguire passo passo le
istruzioni della funzione di lettura che usi per poter vedere il contenuto
del file, un blocco alla volta. Se lo stdio non e` compilato con le
opzioni di debug, allora il debugger non sa cosa c'e` dentro le funzioni
di lettura e non puo` fare altro che eseguirle atomicamente, mostrandoti
il nuovo stato solo dopo che sono state completate. In tale circostanza,
vedresti nel buffer solo l'ultimo blocco letto. Se il sistema che usi
ammette i watch hardware, potresti impostare un watch sul contenuto del
buffer per vedere ogni volta che viene modificato, ma non garantisco che
funzioni.. e` solo un'idea che mi e` venuta in mente ora.
Saluti,
Marco
-- 
To email me, remove the no_ and _spam from my address.

 contenuto dei registri e sono quelli "veri", non simulati, della CPU.
No no, L'IDE  simula proprio. i sorgenti sono compilati per un DSP che non è 
fisicamente presente, ed io monto un BIOS che simula il lavoro di questo 
DSP; chiaro che poi usa i registri del mio processore, ma in maniera 
simulata insomma cioè non sono istruzioni macchina x pentium, sono 
istruzioni macchina per un altro processore che vengono simulate (in breve 
tradotte con combinazioni di altre)  sul mio..

 funzioni.. e` solo un'idea che mi e` venuta in mente ora.
E' un'ottima idea, e la stavo già provando ieri solo che con tutti quei dati 
della struttura FILE non sapevo quale osservare.
Ora che so che
1) devo guardare l' unsigned char *buf
2) il buffer si carica quando è vuoto ( quindi anche quando eseguo fopen() )
sono apposto perchè mi basta un breakpoint dopo l'fopen() e andarmi a 
guardare il buffer nella watch window e il file da windows con un editor 
esadecimale x riscontrare o meno la buona riuscita dell'operazione!!
Nn mi resta che sperare...
PS: mi spiace darvi tante noie ma è davvero difficile utilizzare questo 
compilatore, perchè sebbene implementi un ottimo debugger (*grazie) presenta 
delle regole di compilazione molto strane (tipo quella di settare le 
variabili dentro il main o cmq dentro le funzioni e prima dei blocchi di 
codice "esecutivo" altrimenti non si riesce ad attribuirgli un valore e mi 
da errori) 

 int index
 Ok risolto era *buf 

 pasto...
...
Usare i campi interni della struttura FILE e' una pessima idea (quanto 
meno ti porta a scrivere programmi non standard).
La sicurezza che tutto sia OK con la fopen te la da'  direttamente il 
valore di ritorno della fopen: se qualcosa andasse storto avresti un 
valore NULL.
Voler andare ad usare i campi di FILE e' contrario al principio dell' 
information hiding che e' uno dei pilastri per poter gestire programmi 
complessi.
Giorgio

 tradotte con combinazioni di altre) sul mio..
Ho capito, è un emulatore.


 information hiding[...]
Io, molto meno diplomaticamente, avrei detto che č una "stronzata" ;-)


 Ho capito, è un emulatore.
simulatore emulatore come vuoi...

 meno ti porta a scrivere programmi non standard).
Io non dovevo usarli, dovevo solo fare un controllo in runtime una sola 
volta per essere certo che un certo file fosse caricato;
Cioè guarda posto due righe di codice x capirsi:
FILE *puntfilein;
int buffer_in[3]
main(){
    puntfilein = fopen("bibliografia.txt", "rb");
    fread(buffer_in,4,3,puntfilein);
}
//non va non mi carica il buffer_in... mi si impalla e sta li...
//(NB:compila!)

 //(NB:compila!)
Appunto! bastava controllare il valore di puntfilein:
if ( NULL == ( puntfilein = fopen("bibliografia.txt", "rb") )
      { // scrivi un eventuale messaggio di errore
        // prendi le opportune contromisure 
p.es
. exit, apri un altro 
file, manda un mail di supplica al S.O. ,....
      }
fread(buffer_in,4,3,puntfilein);
...
Tutto standard e niente "usare i dettagli interni".
Giorgio

 Io, molto meno diplomaticamente, avrei detto che è una "stronzata" ;-)
Evidentemente non hai mai sviluppato programmi per sistemi embedded,
con sistemi operativi casalinghi :-)


 con sistemi operativi casalinghi :-)
Non capisco il nesso, sinceramente.


 }
A parte le altre, la riga di fread() č errata. La chiamata giusta č:
fread(buffer_in, 4, 1, puntfilein);


 fread(buffer_in, 4, 1, puntfilein);
ovviamente č
fread(buffer_in, 3, 1, puntfilein);


 Non capisco il nesso, sinceramente.
Semplicemente che quando non hai un SO e delle librerie ben testate
devi andare a seguire passo passo in assembler anche le funzioni di 
libreria.  La richiesta dell'OP non mi meraviglia molto


 libreria. La richiesta dell'OP non mi meraviglia molto
Questo presuppone che il tuo codice sia esatto al 100% e non è così nel caso
dell'OP.


 casalinghi, e` un po` diverso da sviluppare per Win o Linux
Lo standard NON e' per Win o Linux (a parte che il mondo non finisce 
li'). Lo standard menziona sistemi embedded, ma se mi dici dove parla di 
accesso ai campi di FILE per sistemi embedded mi fai un favore.
Perche'  altrimenti quello che trovi in FILE non hai nessuna garanzia 
che sia la stessa cosa dappertutto. Dopo di che l' argomento diventa OT 
per questo NG.
Giorgio

 dell'OP.
ROTFL.


 per questo NG.
Quanto ad essere OT se ti sembra che un commento al tuo post lo sia, 
rileggiti il manifesto di i.c.l.c
=========
Il newsgroup tratterà di qualsiasi dialetto del linguaggio C, in modo
particolare del vecchio K&R e di quello specificato dall'istituto americano
ANSI come standard "ANSI X3.159-1989" e ratificato dall'istituto
internazionale ISO come standard "ISO/IEC 9899:1990". Argomenti compresi:
  - Il linguaggio in generale;
  - Gli algoritmi;
  - Le ottimizzazioni;
  - La portabilità;
  - I sistemi di sviluppo.
=========


 ROTFL.
Ridi perché non hai capito o perché sei idiota ?


 il SO e che le librerie.
Tu che, invece, hai un mondo così illimitato, ce ne citi qualcuno ?


 Ridi perché non hai capito o perché sei idiota ?
Rido per tutte le cazzate che stai scrivendo.
Evidentemente hai studiato bene il C, ma non hai
mai scritto una riga di codice per un VERO progetto.
Ciao
Giovanni
PS:  Oltre che sparare fesserie sai anche essere molto maleducato


 
Hai mai sentito parlare o sviluppato per un microcontrollore?
Ciao
Giovanni
PS:  Oltre che sparare fesserie sai anche essere molto maleducato


 PS: Oltre che sparare fesserie sai anche essere molto maleducato
Perché ti ho detto che sei un idiota ? ma è vero ! :-)


 Hai mai sentito parlare o sviluppato per un microcontrollore?
No, ma so riconoscere quando qualcuno scrive stronzate.


 Inviato via 
http://arianna.libero.it/usenet/


On 06/03/05 18:07, Andrea Laforgia wrote:
Grazie.  Pero` finiscila di rompere i coglioni.


 Grazie. Pero` finiscila di rompere i coglioni.
Taci.


 Sei in buona compagnia.
Taci.
