Newsgroup: it.comp.lang.c
Titolo: CR e LF

Scusate la domanda elementare, c'e' qualcuno che mi può spiegare la
differenza di comportamento tra UNIX e WIN32 nell'interpretare '\n'?
Quando batto il tasto di invio su una console di win32 questa riceve un
byte a 0x0a o a 0x0d (a me sembra il primo)? Oppure riceve due byte con
entrambi?
Grazie
Raffaele.

Questo riguarda più che altro l'assembler, o meglio come i progettisti
dei sistemi operativi hanno deciso di implementare il segnale di
ritorno a capo.
In windows e dos il ritorno a capo viene interpretato dome entrambi i
segnali CR e LF (0x0D e 0xOA), in UNIX semplicemente con =xOD, mentre
in Macintosh solo con 0x0A.
E' il compilatore che provvede ad adattare '\n' perché venga
interpretato correttamente dal sistema operativo in questione.
Curiosità: mi sembra con alcuni compilatori per Windows sia possibile
far interpretare '\n' semplicemente come newLine, seza far tornare a
capo il cursore, ma io non ho mai provato e francamente non ne vedo
molto l'utilità.
Paolo Mossino      
pmo...@tin.it
 
pmos...@edu.al.unipmn.it


you wrote :
#Scusate la domanda elementare, c'e' qualcuno che mi può spiegare la
#differenza di comportamento tra UNIX e WIN32 nell'interpretare '\n'?
#Quando batto il tasto di invio su una console di win32 questa riceve un
#byte a 0x0a o a 0x0d (a me sembra il primo)? Oppure riceve due byte con
#entrambi?
Il problema non riguarda propriamente il linguaggio, quanto il sistema
operativo adottato.
La soluzione e' semplice : DOS/Windows interpreta '\n' come sequenza
di byte CR+LF, mentre Unix come LF.
L'adozione di un unica sequenza di escape in C serve appunto a rendere
il linguaggio indipendente dalla piattaforma di utilizzo e ne assicura
la portabilita' da questo punto di vista.
Andrea Laforgia        (
andrea_...@bigfoot.com
)
----------------------------------------------------
There is nothing better for understanding a kangaroo
than seeing it jump.
----------------------------------------------------

 di byte CR+LF, mentre Unix come LF.
Sembra che sia in UNIX che in Win32 premere il tasto invio corrisponda a un
'\r' piuttosto che a un '\n', infatti una mia piccola funzione che filtra i
caratteri che arrivano da un client salta il controllo:
if (ch == '\n')
mentre "vede":
if (ch == '\r')
ogni volta che viene inviato un 'return' al server.
(N.B. Il server gira sotto win32 e ogni volta che premo 'return' sul client,
sia che questo sia un client UNIX o Win32, al server arriva sempre un '\r' )
Ora secondo le tabelle ASCII 0x0d corrisponde a '\r' e in effetti se nel
controllo sostituisco '\r' con '0x0d' tutto funziona regolarmente, però
tutto questo mi sorprende in quanto mi era sempre stato detto che in un
compilatore C il tasto di 'retrun' era associato a '\n'.
Comunque ora la funzione 'funziona' ^__^ e questa e questa cosa è molto
bella!!!
Grazie a tutti per l'interessamento.
Raffaele

 compilatore C il tasto di 'return' era associato a '\n'.
Ti era stato detto male.
EMG

 controllo CR, non al carattere speciale del C '\r'.
Non mi confondo, 0x0d ha come nome CR ma in tutti i sistemi viene associato a
'\r'.
(C a reference manual, pag. 364).
Raffaele

 (C a reference manual, pag. 364).
Ripeto: ti confondi. Sulla tabella ASCII non troverai mai il simbolo
'\r' in quanto questo è specifico del linguaggio C mentre l'ASCII è un
codice indipendente dal linguaggio. Il C offre, appunto, il carattere
speciale '\r' che dovrebbe venire interpretato su tutti i sistemi come
"ritorno carrello" indipendentemente dal codice di quest'ultimo.
EMG

 Ripeto: ti confondi. Sulla tabella ASCII non troverai mai il simbolo '\r'
(C a reference manual, pag. 364).
Raffaele.

 (C a reference manual, pag. 364).
Su di un manuale C trovi ovviamente ciò che riguarda il C. Ma il simbolo
'\r' non ha senso al di fuori del linguaggio mentre la tabella ASCII è
uno standard che ne è indipendente.
EMG

you wrote :
#> La soluzione e' semplice : DOS/Windows interpreta '\n' come sequenza
#> di byte CR+LF, mentre Unix come LF.
#
#Sembra che sia in UNIX che in Win32 premere il tasto invio corrisponda a un
#'\r' piuttosto che a un '\n', infatti una mia piccola funzione che filtra i
#caratteri che arrivano da un client salta il controllo:
#if (ch == '\n')
#mentre "vede":
#if (ch == '\r')
#ogni volta che viene inviato un 'return' al server.
Non ha senso interpretare '\n' e '\r' in input, essi hanno valore solo
per l'output.
O meglio, non e' possibile interpretarli in modo portabile.
#Ora secondo le tabelle ASCII 0x0d corrisponde a '\r' e in effetti se nel
#controllo sostituisco '\r' con '0x0d' tutto funziona regolarmente, perň
#tutto questo mi sorprende in quanto mi era sempre stato detto che in un
#compilatore C il tasto di 'retrun' era associato a '\n'.
Ti sbagli : non esiste alcuna associazione tra "tasto" e "sequenza di
escape", ma solo tra "sequenza di escape" e "sequenza di byte" da
interpretare come "sequenza di ritorno a capo".
........................................................
.                                                      .
. Andrea Laforgia        (
andrea_...@bigfoot.com
) .
.                                                      .
........................................................

you wrote :
#Hai ragione la mappatura del tasto di 'invio' dipende dal sistema operativo.
#Comunque io credevo che ci fosse corrispondenza tra output e input, infatti
#pensavo che, se per ottenere un "new line" in output bisogna scrivere nel codice
#'\n', allora anche in input il tasto di invio fosse mappato con '\n', ma non è
#così.
E' cosi', ma solo nell'ambito dello stesso ambiente di partenza.
'\n' e' la soluzione portabile dell'invio per l'output ed ovviamente
non si puo' assicurare portabilita' per l'input, se non nello stesso
ambiente di lavoro !


 interpretare come "sequenza di ritorno a capo".
Forse non sarŕ una associazione standard, ma ho verificato che sia sotto UNIX
che sotto WIN32 il carattere inviato quando viene premuto il tasto 'return' č
proprio '\r'.
Comunque, se la cosa non č standard, come posso far capire sul mio server se č
arrivato un 'invio' dal client in maniera standard? Non sarebbe bello che un
client su un sistema operativo diverso da UNIX e WIN32 non funzionasse per
questo motivo.
Grazie a tutti per l'attenzione.
Raffaele.

you wrote :
#Forse non sarą una associazione standard, ma ho verificato che sia sotto UNIX
#che sotto WIN32 il carattere inviato quando viene premuto il tasto 'return' č
#proprio '\r'.
Continuo a non capire che cosa vuoi dire.
Ti ripeto che non ha senso dire "il carattere inviato quando viene
premuto il tasto "return" e' '\r'" proprio perche' '\r' ha senso solo
per l'output e non per l'input, nel senso che ad esso potrebbe anche
non corrispondere un solo carattere, ma una sequenza di byte.
La sicurezza che alla sequenza '\r' corrisponda sempre e solo un byte
non te la da' nessuno, in quanto l'adozione di una sequenza di escape
fa proprio si' che si prescinda da tali particolari.
Per farti un esempio, potrebbe esserci una piattaforma per la quale
tale sequenza nasconde una serie di piu' byte, ma il programmatore
utilizzerebbe sempre e solo '\r' (da qui ne deriva la portabilita' del
codice).
Per dimostrarti, poi, che cio' che dici non e' esatto, se provi ad
eseguire il seguente programma :
#include <stdio.h>
main()
{
    int c ;
    while ( ( c = getchar() ) != EOF )
    {
          if ( c == '\r' ) puts( "return" ) ;
          else
          if ( c == '\n' ) puts( "newline" ) ;
    }
}
Sulla mia piattaforma DOS+Win95, alla pressione del tasto invio,
ottieni come output "newline" e non "return".
#Comunque, se la cosa non č standard, come posso far capire sul mio server se č
#arrivato un 'invio' dal client in maniera standard? Non sarebbe bello che un
#client su un sistema operativo diverso da UNIX e WIN32 non funzionasse per
#questo motivo.
La sequenza 'invio' non ha una definizione standard e per questo
motivo sarebbe bene che il server sapesse a priori che tipo di
sequenza aspettarsi.
E' per questo che nelle comunicazioni client-server si adottano dei
protocolli particolari.
........................................................
