Newsgroup: it.comp.lang.c
Titolo: HELP : il carattere EOF...

Salve a tutti, sono nuovo di questo ng.
Sto studiando informatica all'università di Venezia e ho appena iniziato a
studiare il linguaggio C. Il problema di questo stupidissimo programma che
conta le righe di un testo digitato dall'utente è EOF.
Ho fatto un cliclo WHILE che dovrebbe uscire ,restituendo il numero di
righe,
quando viene dato come input il carattere speciale EOF...tutto questo non
avviene e il mio programmino entra in un ciclo infinito....
C'è qualcuno che ha voglia di aiutarmi?
(segue programma a fine messaggio)
Grazie
Nicola
http://www.geocities.com/southbeach/keys/4044/
/* conta le le line di input */
# include <stdio.h>
main()
{
 int c, nl;
 nl = 0;
 while ((c = getchar()) != EOF)
 {
  if (c == '\n')
  {
   ++nl;
  }
 }
 printf("%d\n",nl);
}

avviene e il mio programmino entra in un ciclo infinito....
Ho riscritto il programma, ma non cambia nulla rispetto a prima.
Sei sicuro che non funzioni ? 
E' talmente semplice che cosi' com'e' non dovrebbe dare problemi.
Piuttosto se lavori in un ambiente DOS/Windows95 ti basta premere F6 o Ctrl+Z
per ottenere il carattere EOF in fase di input.
Sul mio PC funziona.
#include <stdio.h>
int main()
{
    int c, nl = 0;
    while ((c = getchar()) != EOF)
          if (c == '\n') ++nl;
    printf("%d\n",nl);
    return 0 ;
}
Skyscraper (apprezzatelo adesso : eviterete la coda)
----------------------------------------------------
 
andrea_...@bigfoot.com
----------------------------------------------------
--
Posted from 
itaca.ulysse.it
 [195.223.254.1]
via Mailgate.ORG Server - 
http://www.mailgate.org

}
ciao
Salvo

 [...]
Attenzione: EOF e' uguale a -1. 'char c' funziona solo se i char sono per
default signed. Per sicurezza e' meglio usare int o 'signed char'.

 [...]
Ctrl-Z (o F6 su PC) tronca i file di testo (almeno con DJGPP e su Unix).
Per ottenere EOF, Ctrl-Z deve essere inviato come primo carattere della
linea (seguito da \n): tronca una linea vuota (butta via se stesso e \n) e
di conseguenza la filbuf() (chiamata da getchar) si ritrova senza caratteri
dopo aver fatto la read(stdin) e ritorna EOF.
Ctrl-D, che, secondo la documentazione del DJGPP dovrebbe ritornare EOF,
ritorna se stesso (0x04).
Quindi il programma e' corretto, ma EOF deve essere inviato come primo
carattere di una linea di input (almeno cosi' vanno le cose in UNIX e in
DOS con il DJGPP)

 avviene e il mio programmino entra in un ciclo infinito....
Dunque, se lo compilo con il TurboC++ 1.01 funziona benissimo. Se lo
compilo con il DJGPP invece 'sente' il CTRL-Z inserito nell'input solo
se questo si trova all'inizio di una riga. ???
EMG

 default signed. Per sicurezza e' meglio usare int o 'signed char'.
'signed char' però, se non erro, è limitato al range 0 - 127 (nella
parte positiva) e quindi sarebbe insufficiente a rappresentare l'intero
set di caratteri esteso.
EMG

...

Vero, anche se in realta' puoi rappresentarli utilizzando i numero
negativi:
signed char -127 ==> unsigned char 129, puoi tranquillamente assegnare a
'signed char' numeri maggiori di 127, sicuro di ottenere il carattere
giusto (sicuro ? E' da verificare. Funziona per qualunque rappresenzazione
in complemento a due).
Il DJGPP usa di default i signed char e non da' nessun problema sul set
esteso.
Pero' bisogna stare attenti all'ordinamento (127 > 129 [-127] per i signed
char).

DOS con il DJGPP)
Io se che nel caso del DOS vale la stessa regola del "copy con file.txt" cioe' 
premendo F6 o Ctrl+Z viene scritto il carattere ASCII 26 (non su disco) ovvero
quello che in ambiente MS-DOS viene considerato il carattere EOF ed il file
viene troncato.
Sulla mia macchina con questo sistema, compilato col DJGPP, ritorna il numero
esatto di linee.


Un bel giorno, tutt'a un tratto Enrico Maria Giordano si mise a scrivere :

Sulla mia macchina, compilato con il DJGPP, l'output del programma e'
prima linea
seconda linea
terza linea
^Z
3


 negativi:
Scusa se insisto ma non puoi rappresentare 256 caratteri piů l'EOF con
un signed char, giusto?
EMG

 terza linea^Z
Allora il ^Z non viene sentito.
EMG

Allora il ^Z non viene sentito.
Capito ! ;)
Si' e' vero, succede la stessa cosa anche a me.


Grazie a tutti !
Ciao
Nick
http://www.geocities.com/southbeach/keys/4044/
ICQ : 26032113




sinistra, prima dell'assegnamento.
Attenzione ! questa regola potrebbe valere solo per i file di testo.
Sulla mia macchina il valore EOF viene dapprima convertito in 255 e poi in -1,
in virtu' del fatto che il valore -1 di int viene convertito nel valore massimo
dell' "unsigned char" che, a sua volta, viene convertito in -1 nel "signed char"
(che circolo assurdo !! :).
E come la mettiamo, nel caso ci fosse una carattere nello stream di input,con
valore uguale a 255, cioe' valore massimo ottenibile per il tipo "char" ?
In questo caso serve dichiarare c come int, per far si' che, oltre al numero
massimo di valori contenibili in "char", ci sia spazio anche per il -1.
Difatti, cercando di leggere con il tuo ciclo un file binario, ci si ferma,
inevitabilmente, prima della fine reale del file.


 
Hai ragione, in input non puoi  distingure fra EOF e 255 (-1). Ecco perche'
uso sempre 'int', me ne ero dimenticato!
Saluti, Alberto.

 
Forse dipende dalla versione (io uso ancora gcc 2.7.2.1 e relative
librerie). Se non inserisci Ctrl-Z come primo carattere il programma non si
ferma. Ho controllato nei sorgenti di filbuf() da cui risulta che, ricevuto
il carattere 0x1A (Ctrl-Z), la linea viene troncata e vengono ritornati i
caratteri rimanenti senza impostare EOF. Solo se, dopo il troncamento,
filbuf() trova 0 caratteri nel buffer, ritorna EOF.

inevitabilmente, prima della fine reale del file.
Come ti dicevo, si parlava di file di testo. Comunque in questi casi esiste
anche la funzione "feof".


 Infine, non occore dichiarare c come int,
Invece temo sia indispensabile dato che la funzione getchar()
restituisce proprio un int (tutti i valori tra 0 e 255 più il -1, range
di valori non contenibile in un char che sia signed o unsigned).
EMG

filbuf() trova 0 caratteri nel buffer, ritorna EOF.
Si, hai perfettamente ragione, succede la stessa cosa anche a me.


anche la funzione "feof".
In *tutti* i casi si usa un "int".
