Newsgroup: it.comp.lang.c
Titolo: EOF

su un manuale ho letto che per individuare la fine di un file aperto in modo
binario non si deve usare EOF perchč potrebbe esserci un byte significativo
che perň ha valore -1 ed essere considerato come la fine del file, quindi un
codice di questo tipo sarebbe sbagliato:
FILE *fp=fopen("c:\\prova.txt","rb");
  while(getc(fp)!=EOF)
   //...
  printf("%d\n",cnt);
perň a me funziona benissimo su qualunque file, e anche se creandolo ho
appositamente inserito un EOF nel mezzo lo conta come byte 255. Se non
sbaglio infatti un byte che vale -1 in binario č 11111111, mentre eof che č
un intero -1 in binario č 11111111111111111111111111111111 e quindi un
byte -1 non č uguale a eof.
mi potete dire se sbaglio io o se sbaglia il manuale? spero che sia tutto
chiaro...
grazie, ciao

 grazie, ciao
fgetc() reads the next character from stream  and  returns
it  as  an  unsigned char cast to an int, or EOF on end of
file or error.
getc() is equivalent to fgetc()  except  that  it  may  be
implemented  as  a  macro which evaluates stream more than
once.
e' "unsigned char cast to an int" la chiave dell'arcano. Il -1
all'interno del file non ti sara' mai restituito come -1 ma come
(unsigned char)(-1)
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

.:'DevarajA':. wrote:
[cut]
Al contrario, io so che per la massima portabilità è meglio controllare 
l'EOF
perché potrebbe cambiare da sistema a sistema.
Unix: <invio> ctrl+d
msdos,win: ctrl+z
Saluti
-- 
-> Linux Registered User #365929
-> cikko*
despamming.com
-> GnuPG KeyID=0xAF86FD7D
-> 
http://www.cikko.tk
" U culu se para quannu e sulu... ca pue, accumpagnatu, se trova imparatu! "

 che però ha valore -1 ed essere considerato come la fine del file, 
EOF *non* e` un carattere[1]! E non e` neppure presente nel file, non
puoi "scrivere" un EOF in mezzo ad un fpile. E` un valore convenzionale
che viene restituito da alcune funzioni di IO per indicare la fine del
file. getc e simili restituiscono un int proprio perche` tutti i
possibili valori di un unsigned char sono valori leggitimi per un byte
all'interno del file.
Luca
[1] Anche se nella codica ASCII ci sono "End of varia roba" non hanno
nulla a che fare con EOF del C.
-- 
Home: 
http://kronoz.cjb.net
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni

 codice di questo tipo sarebbe sbagliato:
Nei file  tuoi puoi scrivere valori ad 8 bit, questi possonoe essere 
valori compresi tra 0 e 255 (estremi inclusi), nei file testo alcuni di 
questi valori hanno un particolare significato, il EOF ha un suo valore 
numerico (non ho la tabella sottomano e non ricordo i valori).
Nei file Binari tutti questi valori sono accettati come codici validi, 
la fine del file viene indicata in base alla lunghezza del file (quando 
arrivi alla fine e' il sistema che segnala l'EOF).
Nei file di testo c'e' la doppia possibilita' o si cerca il carattere di 
EOF, pero' tutti gli editor che ho visto non lo usano, forse l'ultimo 
era WordStar, per cui anche in questo caso ci si basa sulla lunghezza 
del file.
ciao

 del file.
Questo no :( Per i file di testo il meccanismo e` lo stesso dei file
binari. Terminato il file la libreria provvede a restituire EOF.
Luca
-- 
Home: 
http://kronoz.cjb.net
"New processes are created by other processes, just like new
 humans. New humans are created by other humans, of course,
 not by processes." -- Unix System Administration Handbook

 
La libreria potrebbe dipendere dal sistema,
ho preso un testo che conteneva il codice 1A e ho inserito con un editor 
esadecimale del testo aggiuntivo dopo il codice
#include <stdio.h>
main()
{
  FILE *f;
  char ch;
  f=fopen("li.bas","r");
  if(f)
  {
   while(!feof(f))
   {
    fread(&ch,sizeof(char),1,f);
    if(!feof(f))putchar(ch);
   }
   fclose(f);
  }
}
si ferma a leggere sul codice 1A, ammetto, magari dipende dal sistema 
operativo (questo non lo so ma e' molto facile che lo sia).
ciao

 operativo (questo non lo so ma e' molto facile che lo sia).
A parte la dichiarazione farlocca di main, il file e` aperto in
modalita` testo, quindi si comporta in modo definito se e solo se i
caratteri sono stampabili oppure rappresentano una delle sequenze escape
definite dallo standard. Inoltre l'uso di 0x1a[1] come carattere di EOF
e` palesemente in violazione dello standard ISO.
Stiamo comunque parlando di preistoria, visto che il linguaggio C e`
diventato standard ANSI nel 89 (DOS 1.0 e` stato rilasciato 8 anni
prima), mentre la revisione attuale risale al 99.
Luca
[1] Retaggio del DOS, non sono neppure sicuro che sia sopravvissuto dopo
la 1.0
-- 
Home: 
http://kronoz.cjb.net
Windows NT crashed.
I'm the Blue Screen of Death.
No one hears your screams.

E comunque, a parte tutto, è normale che dopo 0x1A il tuo programma ti 
dia eof.
Perchè *comunque* dopo 0x1A non hai scritto null'altro, quindi il s.o. 
rileva una fine-del-file subito dopo 0x1A. Ma questo non significa che 
quel carattere venga interpretato come eof. Prova a terminare un file 
con il carattere 0x2E o anche 0xF1: qualunque carattere tu usi come 
terminatore del file, carai sempre nell'errore di pensare che QUEL 
carattere indicihi la fine del file. Ma non è così, perchè il carattere 
di fine-file viene scritto DOPO qualsiasi cosa scritta da te, e in 
maniera a te trasparente.
Infatti prova a scrivere qualcosa dopo il carattere 0x1A nel file del 
tuo esempio, e noterai che il tuo programma in effetti non vedrà 0x1A 
come eof ma continuerà la sua lettura :)
-- 
Quando noi ignoranti eravamo di più, tutto era più bello (A. Celentano).
  ___   _   ___ _  _______   _______ ___
|   \ /_\ | _ \ |/ / _ ) \ / /_   _| __|
| |) / _ \|   / ' <| _ \\ V /  | | | _|
|___/_/ \_\_|_\_|\_\___/ |_|   |_| |___|

 
c'era scritto altro, infatti alcuni editor, sopratutto gli ultimi 
riescono a leggere olre, forse aprono i file di testo in modo binario.
ciao

 ciao
Ciao :)
-- 
Quando noi ignoranti eravamo di piů, tutto era piů bello (A. Celentano).
