Newsgroup: it.comp.lang.c
Titolo: Funzioni posizionamento in un file

Ho qualche dubbio sulle funzioni di riposizionamento nei files:
1) ftell() e fseek():
    nel libro di Kelley & Pohl, c'è scritto che la correttezza dell'operato
delle funzioni è assicurata solo nel caso di file binari, e che quindi sotto
msdos i files di testo vanno aperti come binari. Solo che, nello stesso
libro e nel K&R, nel reference sulle funzioni, c'è scritto che pewr fseek in
un file binario il valore place può valere SEEK_SET, SEEK_CUR O
SEEK_SEEK_END, con ofset positivo, 0, o negativo, mentre per quelli di testo
offset dovrebbe vaslere 0 o un val restituito da ftell(),  con place
SEEK_SET. Ora:
    a) funzionano o no con i files di testo?
    b) perchè quelle limitazioni sui valori di ftell nel caso di files di
testo?
Il libro di Kelley & Pohl dice poi che ftell in caso di file binari
restituisce il numero di byte dall'inizio del file, ma che in caso di files
di testo il valore dipende dal sistema? Perchè? Inoltre dice che la
differenza tra due valori restituiti su un file di testo non corrisponde
necessariamente al numero di caratteri letti o scritti. Perchè?
2) fsetpos() e fgetpos(): quando sono utilizzate? Funzionano correttamente
su files di testo acneh sotto MS-DOS?
Grazie
--
Marco Iannaccone     
marc...@tin.it
ICQ: 18748121           Tolkien
"I've... seen things you people wouldn't believe. Attack ships on fire off
the shoulder of Orion.
I watched C-beams... glitter in the dark near the Tanhauser Gate. All
those... moments will be lost... in time..., like... tears... in... rain."
FAQ it.comp.lang.c: 
http://www.programmazione.it/linguaggi/c/itcomplangc.htm
FAQ it.comp.lang.c++: 
http://www.programmazione.it/linguaggi/c/lang_faq.htm

 Funzionano correttamente su files di testo acneh sotto MS-DOS?
  Queste due funzioni sono piu` complesse delle precedenti e la
struttura /fpos_t/ da esse utilizzata potrebbe garantire quello che
cerchi. Una breve discussione sulle differenze tra queste due classi di
funzioni la trovi a:
 
http://www.eskimo.com/~scs/C-faq/q12.25.html
	Alla prossima,
		Marco

necessariamente al numero di caratteri letti o scritti. Perchč?
Per i motivi detti sopra.
--
Andrea Laforgia (ICQ 87230455)

 su files di testo acneh sotto MS-DOS?
Credo ci sia lo stesso problema.
EMG

rappresentato da uno o due bytes a seconda del sistema operativo.
da uno o + bytes ;)


 da uno o + bytes ;)
Non mi dire che c'č qualche sistema che lo rappresenta con piů di due
bytes!
EMG

bytes!
E perche' no ? :)


 E perche' no ? :)
Va bene, ho capito lo scherzo. :-) Comunque certo, in linea di principio
č possibilissimo.
EMG

Va bene, ho capito lo scherzo. :-)
L'alfabeto giapponese (che e' scorretto pero' chiamare alfabeto
n.d.p.) contiene oggi almeno 50,000 caratteri (ma bisognerebbe
chiamarle parole). Se aggiungiamo l'alfabeto per bambini (katakana
secondo la mia ricca collezione di  fumetti giapponesi n.d.p.) si
supera di molto lo spazio a disposizione in due byte.
Facciamo il caso poi che un Giapponese voglia spedire un testo ad un
Coreano che lo debba correggere e tradurre in Cinese. Unicode va molto
stretto a chi usa gli ideogrammi.
++++
Tanenbaum  insegna che ci sono tuttora grandi polemiche da parte della
societa' civile Giapponese su come e' composto il comitato Unicode per
la scelta dei caratteri da inserire nell'alfabeto.
-- 
Tieni per te il Papero se vuoi la mia email
Intel entra in scena nella guerra dei compilatori.
Sito Papero -> 
http://utenti.tripod.it/papero

la scelta dei caratteri da inserire nell'alfabeto.
Ma questo alfabeto e' gia' definito o e' ancora in fase di sviluppo? I
caratteri ASCII sono sempre i primi 128 o li hanno spostati?
Saluti,
    Mardy

Unicode va molto stretto a chi usa gli ideogrammi.
Non c'entra Unicode con quanto si sta discutendo.
Unicode e' semplicemente uno standard per consentire di rappresentare
anche caratteri che richiedono una dimensione maggiore del normale, ma
non ha influenza sulla dimensione del "byte".
--
Andrea Laforgia (UIN 87230455)
----------------------------------------------------------
Non scrivetemi per e-mail, se non richiesto espressamente.
No replies in private e-mail, unless explicitly requested.
----------------------------------------------------------

Va bene, ho capito lo scherzo.
Ho fatto l'esempio di uno standard di codifica a due byte (Unicode
n.d.p.) che e' palesemente e intrinsicamente carente per risolvere
certe problematiche. Dal che si deduce (o se vuoi non se ne deduce un
bel niente n.d.p.) che un sistema in cui i caratteri sono
rappresentati da piu' di 2 byte possono essere perfettamente sensati.
Saluti e Paperi


caratteri ASCII sono sempre i primi 128 o li hanno spostati?
Sarebbe molto stupido spostarli. Sarebbe molto stupido spostare
qualsiasi carattere gia' assegnato.
Saluti e Paperacci.


Ho fatto l'esempio di uno standard di codifica a due byte (Unicode
Stai confondendo.
Il C standard prevede l'esistenza dei normali caratteri a 1 byte e dei
caratteri estesi a 2 byte. Il fatto che il linguaggio, in seguito
all'introduzione di UNICODE, supporti caratteri siffatti, non ha
alcuna influenza sul numero di bit utilizzati per ogni carattere
/normale/. Ripeto, non c'entra nulla con quanto si stava dicendo ;)


Stai confondendo.
Ops... scusate... avevo inteso un'altra questione.
In ogni caso, ribadisco che quanto stai affermando non c'entra con
quanto si sta discutendo e cioe' la rappresentazione della sequenza di
fine linea.


rappresentato da uno o due bytes a seconda del sistema operativo.
sia anche essa scorretta. Su NT un fine linea puo' essere un byte, o
due byte a seconda del set di caratteri usati. Se la tua applicazione
usa il set di catatteri ANSI o MBCS su macchina Intel vale un byte (8
bit), mentre con UNICODE su Intel vale 2 (16 bit).
Contro esempio. Apri su NT un file Unicode con Notepad, e aprilo con
un altro editor. Il secondo lo trattera' come file binario.
Lo standard ti dice di usare \n o \r, non certo le sue trascodifiche
binarie. Cosa sia \n dipende non solo dal S.O., ma anche da *come*
l'applicazione gira !! Quindi meglio non fare assunzioni su di essi.
-- 
Tieni per te il Papero se vuoi la mia email


due byte a seconda del set di caratteri usati. 
Su NT vale uno o due byte, perche' NT e' un ibrido che unisce
caratteristiche di Windows e caratteristiche di Unix.
Non c'entra Unicode.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

 Infatti, ma e' assicurato che 1 carattere = 1 byte.
Mi ricordavo che l'assunzione era unicamente sizeof( char ) == 1.
Sbaglio?
EMG

Sbaglio?
E' quello che ho detto.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

 E' quello che ho detto.
Un momento: il fatto che sizeof( char ) sia uguale ad uno non significa
che il char abbia dimensione di un byte. Potrebbe avere dimensione dieci
bytes e la sizeof( char ) restituire sempre uno. Almeno mi pare...
EMG

bytes e la sizeof( char ) restituire sempre uno. Almeno mi pare...
Ti sbagli.
sizeof( char ) = 1 significa che un char e' lungo 1 byte.
Non avrebbe senso l'uso di sizeof, se fosse come dici.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

 Non avrebbe senso l'uso di sizeof, se fosse come dici.
Mah, probabilmente ricordo male io...
EMG

Enrico,

  Avete problemi con i vostri manuali? ;)
<cite src="K&R2#A7.4.8" name="Operatore sizeof">
	L'operatore /sizeof/ produce il *numero di byte* richiesti 
	per la memorizzazione di un oggetto del tipo del suo  
	operando. [...] Quando l'operatore /sizeof/ viene applicato 
	ad un /char/, *il risultato e` 1*.
</cite>
  Ergo: la dimensione di un /char/ e` definita dallo standard pari ad 1
byte. 
  D'altra parte, il byte e` la piu` piccola unita` di memoria
indirizzabile: se immagini il dominio dei /char/ come l'insieme dei
caratteri rappresentabili sulla piattaforma, vedi che esso coincide con
l'insieme dei valori che un byte puo` assumere, naturalmente riferendoci
al termine "carattere" con la sua vecchia (pre-Unicode) definizione.
	Alla prossima,
		Marco

 al termine "carattere" con la sua vecchia (pre-Unicode) definizione.
Qui non ci siamo piu'.  Un "byte" e' definito in ISO/IEC etc. punto
3.6 come (libera traduzione ed enfasi mie): "unita' INDIRIZZABILE di
memoria larga ABBASTANZA da contenere TUTTO IL CHARACTER SET
FONDAMENTALE DELL'AMBIENTE di esecuzione".  Quindi e' possibile sia
che: 1) l'ambiente di esecuzione sia unicode o ancora piu' complesso,
con bytes di assai piu' di 8 bits; o che 2) l'ambiente di esecuzione
sia il locale C per i cui caratteri basterebbero 8 bits, ma un byte ne
occupa assai di piu' (ho gia' fatto in passato l'esempio di processori
DSP per cui sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long)
ed un byte e' di 64 bits).
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 ed un byte e' di 64 bits).
  Il C--fortunatamente--non definisce il concetto di bit, se non nel
nuovo standard per le dimensioni minime dei tipi. Per cui non capisco
perche` tu non sia d'accordo con me, dato che io di bit non ho mai
parlato.
  D'altra parte, l'Unicode e` implementato su molte piattaforme come un
doppio /char/ e doppio byte, per cui non rientra ne` nella definizione
ISO di /char/-byte, ne` in quella mia di byte, ne` in quella del K&R2 di
/char/.
  Inoltre, su moltissime altre (e.g.: IBM MVS) non e` e, probabilmente,
non sara` mai implementato, per cui l'ho accuratamente eliminato dalla
mia trattazione, proprio per evitare commenti del tipo "ma Windows usa
l'Unicode a due byte", usualissimi, come a te certamente noto, sulla
controparte internazionale di questo newsgroup.
	Alla prossima,
		Marco

 Avete problemi con i vostri manuali? ;)
No, ho problemi con la mia memoria...
EMG

 ed un byte e' di 64 bits).
Meno male, pensavo gią di mostrare segni di perdita senile della
memoria... :-)
EMG

 parlato.
Ok, capito il disguido: con byte non si intendono 8 bit.
EMG

caratteristiche di Windows e caratteristiche di Unix.
Il fatto che ti sia piu' simpatico  NT di Unix qui non centra.
Storicamente in Unix un carattere e' di un byte. In NT un carattere e'
di 2 byte perche' queste sono state le specifiche progettuali. NT e'
nato cosi', e non so cosa farci. Anche Java e VB al loro interno usano
stringhe Unicode, mentre in C storicamente una stringa e' fatta di
caratteri da un byte (con segno? senza segno? bho). In C++ non si
entra nel ginepraio di cosa sia una stringa, anche se ci sono i
templati specializzati per stringhe da un carattere o da due.
Il fatto che poi che il S.O. possa tradurti al volo le stringhe da
ANSI a OEM a MBCS a UNICODE nulla centra con l'essere ibrido o meno.
Il fatto che in C++ il w_char sia un tipo fondamentale non mi sembra
un dettaglio da poco. Io non direi che Unicode non centra nulla,
almeno non lo pensava chi ha fatto lo standard e si e' sentito in
dovere di dare dignita' di tipo al w_char.
++++
Ovvero ho detto una cosa scorretta. Internamente NT tratta le stringhe
sempre e solo a due byte. Usa ANSI porta i programmi ad essere un poco
piu' lenti per le traduzioni che vengono fatte dietro le quinte quando
vengono chiamate le API che hanno parametri stringa.
-- 
Tieni per te il Papero se vuoi la mia email


Io non direi che Unicode non centra nulla,
Davide, tu stai confondendo (e anche molto) la questione.
In NT un carattere NON e' di 2 byte, e' comunque di 1 byte, se esso e'
un "char". E' il "wchar" che e' di 2 byte, ma la natura dei caratteri
Unicode non c'entra col problema che si discute.
Il problema principale e' che non si conosce la lunghezza in byte del
delimitatore di fine riga e questo e' un problema nel trattare il
posizionamento in un file di testo.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

un "char". 
Il mio problema e' conosco male la vostra lingua umana. Il mio
traduttore Papero-Italiano e' del tipo economico.
Dal momento che i programmi non vivono nello spazio Platonico di fatto
i caratteri hanno una dimensione fissa. Come minimo, primo o poi un
carattere lo devi stampare. Nel tuo programma potresti avere
codificato i carattere come formati da entita' a 13 bit, pero' il S.O.
conosce solo il suo formato. Se hai bisogno dei servizi del S.O.
qualcuno deve tradurre. Prima o poi hai sempre bisogno dei servizi del
S.O.
Per NT i caratteri sono Unicode a 16 bit (ti fidi di MSDN?). Su Win9x
i caratteri sono a 8 bit in certe versione, e' una schifezza mista
8+16 in altre.
Se tu stampi a video una stringa ANSI su NT, in realta' il S.O. ti
traduce al volo la stringa. Se tu stampi una stringa Unicode con un
programma C compilato con il VC++ su Win9x (che non sa cosa sia
Unicode) vedrai che stampa perfettamente. In questo caso e' il
run-time che traduce. Probabilmente traduce togliendo la parte alta
delle WORD.
Diro' di piu'. In C una stringa e' per motivi storici zero terminata.
Se guardi le API di NT vedrai che per scrivere dentro una console
(WriteFile e WriteConsole) il terminatore devi toglierlo. In questo
caso, se usi funzioni standard C o standard C++, il traduttore e' il
tuo run-time.
Insomma, io sostengo che di fatto il tuo S.O. , la tua CPU, il tuo
compilatore, definiscono come e' fatta una stringa e cosa e' un
carattere. Che poi il run-time del C o del C++ mascheri il tutto
rendendo la baracca portabile, e' un altro discorso.
Gli standard hanno un solo problema, chi non li rispetta da una
posizione dominante.
-- 
Tieni per te il Papero se vuoi la mia email
