-\chapter{I file: l'interfaccia standard ANSI C}
+ \chapter{I file: l'interfaccia standard ANSI C}
\label{cha:files_std_interface}
Esamineremo in questo capitolo l'interfaccia standard ANSI C per i file,
quella che viene comunemente detta interfaccia degli \textit{stream}.
Dopo una breve sezione introduttiva tratteremo le funzioni base per la
-gestione dell'input/output, mentre tratteremo le caratteristiche più aanzate
+gestione dell'input/output, mentre tratteremo le caratteristiche più avanzate
dell'interfaccia nell'ultima sezione.
\section{Introduzione}
\label{sec:file_stream_intro}
-Come visto in \capref{cap:file_unix_interface} le operazioni di I/O sui file
-sono gestibili direttamente a basso livello con l'interfaccia standard unix
-che ricorre direttamente alle system call messe a disposizione dal kernel.
+Come visto in \capref{cha:file_unix_interface} le operazioni di I/O sui file
+sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
+direttamente alle system call messe a disposizione dal kernel.
Questa interfaccia però non provvede le funzionalità previste dallo standard
-ANSI C che invece sono realizzate attraverso opportune funzioni di libreria,
-che vengono a costituire il nucleo essenziale\footnote{queste funzioni sono
- state implementate la prima volta da Ritchie nel 1976 e da allora sono
- rimaste sostanzialmente immutate.} delle \acr{glibc}.
+ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
+queste, insieme alle altre funzioni definite dallo standard, vengono a
+costituire il nucleo\footnote{queste funzioni sono state implementate la prima
+ volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente
+ immutate.} delle \acr{glibc}.
\subsection{I \textit{file stream}}
\label{sec:file_stream}
Come più volte ribadito l'interfaccia dei file descriptor è una interfaccia di
-basso livello, che non provvede nessuna forma di formattazione dei dati, e
+basso livello, che non provvede nessuna forma di formattazione dei dati e
nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
-In \textit{Advanced Programming in the Unix Environment} Stevens esegue un
-raffronto dell'influenza delle dimensioni del blocco di dati (il parametro
+In \textit{Advanced Programming in the Unix Environment} Stevens descrive una
+serie di test sull'influenza delle dimensioni del blocco di dati (il parametro
\param{buf} di \func{read} e \func{write}) nell'efficienza nelle operazioni di
I/O con i file descriptor, evidenziando come le prestazioni ottimali si
-ottengano quando il buffer dei dati ha la stessa dimensione dei blocchi del
-filesystem (il valore dato dal campo \var{st\_blksize} di \var{fstat}).
+ottengano a partire da dimensioni del buffer dei dati pari a quelle dei
+blocchi del filesystem (il valore dato dal campo \var{st\_blksize} di
+\var{fstat}).
-In questo caso se il porgrammatore non si cura di effettuare le operazioni in
-blocchi di dimensioni adeguate, le prestazioni possono deteriorarsi in maniera
-evidetne. L'interfaccia degli stream provvede da sola la gestione dei dettagli
-della bufferizzazione e dell'esecuzione delle operazioni di lettura e
-scrittura effettive in blocchi di dimensioni appropriate all'ottenimento della
-massima efficienza.
+Se il programmatore non si cura di effettuare le operazioni in blocchi di
+dimensioni adeguate, le prestazioni sono inferiori. La caratteristica
+principale dell'interfaccia degli stream è che essa provvede da sola alla
+gestione dei dettagli della bufferizzazione e all'esecuzione delle operazioni
+di lettura e scrittura in blocchi di dimensioni appropriate all'ottenimento
+della massima efficienza.
Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
-\textit{file stream}, dato che non è più necessario doversi preoccupare di
-gestire i dettagli della comunicazione con il tipo di hardware sottostante, ed
-esso può essere sempre considerato come composto da un flusso (da cui il nome
-\textit{stream}) continuo di dati.
-
-Ma a parte le particolarità della gestione delle operazioni di lettura e
-scrittura, i file stream restano del tutto equivalenti ai file descriptor sui
-quali sono basati, ed in particolare vale quanto visto in
+\textit{file stream}, dato che non è più necessario doversi preoccupare
+dei dettagli della comunicazione con il tipo di hardware sottostante
+(come nel caso della dimensione dei blocchi del filesystem), ed un file
+può essere sempre considerato come composto da un flusso continuo (da
+cui il nome \textit{stream}) di dati.
+
+A parte i dettagli legati alla gestione delle operazioni di lettura e
+scrittura (sia per quel che riguarda la bufferizzazione, che le
+formattazioni), i file stream restano del tutto equivalenti ai file descriptor
+(sui quali sono basati), ed in particolare continua a valere quanto visto in
\secref{sec:file_sharing} a proposito dell'accesso condiviso ed in
\secref{sec:file_access_control} per il controllo di accesso.
\subsection{Gli oggetti \type{FILE}}
\label{sec:file_FILE}
-Per ragioni storiche la struttura di dati che rappresenta un stream è stata
+Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e
contengono tutte le informazioni necessarie a gestire le operazioni sugli
stream, come la posizione corrente, lo stato del buffer e degli indicatori di
stato e di fine del file.
-Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
-queste strutture, ma usare sempre puntatori del tipo \type{FILE *} ottenuti
-dalla libreria stessa (tanto che in certi casi il termine di puntatore a file
-è diventato sinonimo di stream).
-
-Tutte le funzioni della libreria che operano sui file accettano come parametri
-solo variabili di questo tipo, che diventa accessibile includendo l'header
+Per questo motivo gli utenti non devono mai utilizzare direttamente o
+allocare queste strutture, ma usare sempre puntatori del tipo \type{FILE
+ *} ottenuti dalla libreria stessa (tanto che in certi casi il termine
+di puntatore a file è diventato sinonimo di stream). Tutte le funzioni
+della libreria che operano sui file accettano come parametri solo
+variabili di questo tipo, che diventa accessibile includendo l'header
file \file{stdio.h}.
\subsection{Gli stream standard}
\label{sec:file_std_stream}
-Ai tre file descriptor standard (vedi \secref{sec:file_std_descr}) aperti per
-ogni processo, corrispondono altrettanti stream predefiniti per ogni processo,
-che rappresentano i canali standard di input/output prestabiliti; anche questi
-tre stream sono definiti nell'header \file{stdio.h} e sono:
+Ai tre file descriptor standard (vedi \secref{sec:file_std_descr})
+aperti per ogni processo, corrispondono altrettanti stream, che
+rappresentano i canali standard di input/output prestabiliti; anche
+questi tre stream sono identificabili attraverso dei nomi simbolici
+definiti nell'header \file{stdio.h} che sono:
\begin{itemize}
-\item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da cui
- il processo riceve ordinariamente i dati in ingresso. Normalmente è associato
- dalla shell all'input del terminale e prende i caratteri dalla tastiera.
-\item \var{FILE * stdout} Lo \textit{standard input} cioè lo stream su cui
- il processo invia ordinariamente i dati in uscita. Normalmente è associato
- dalla shell all'output del terminale e scrive sullo schermo.
-\item \var{FILE * stderr} Lo \textit{standard input} cioè lo stream su cui
- il processo è supposto inviare i messaggi di errore. Normalmente anch'esso
- è associato dalla shell all'output del terminale e scrive sullo schermo.
+\item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da
+ cui il processo riceve ordinariamente i dati in ingresso. Normalmente
+ è associato dalla shell all'input del terminale e prende i caratteri
+ dalla tastiera.
+\item \var{FILE * stdout} Lo \textit{standard input} cioè lo stream su
+ cui il processo invia ordinariamente i dati in uscita. Normalmente è
+ associato dalla shell all'output del terminale e scrive sullo schermo.
+\item \var{FILE * stderr} Lo \textit{standard input} cioè lo stream su
+ cui il processo è supposto inviare i messaggi di errore. Normalmente
+ anch'esso è associato dalla shell all'output del terminale e scrive
+ sullo schermo.
\end{itemize}
-Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
-tre variabili che possono essere usate come tutte le altre, ad esempio si può
-effettuare una redirezione dell'ouput di un programma con il semplice codice:
+Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono
+effettivamente tre variabili di tipo \type{FILE *} che possono essere
+usate come tutte le altre, ad esempio si può effettuare una redirezione
+dell'output di un programma con il semplice codice:
\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
fclose (stdout);
stdout = fopen ("standard-output-file", "w");
\end{lstlisting}
-ma in altri sistemi possono essere definite come macro, e deve essere pertanto
-usata \func{freopen}.
+ma in altri sistemi queste variabili possono essere definite da macro, e
+se si hanno problemi di portabilità e si vuole essere sicuri, diventa
+opportuno usare la funzione \func{freopen}.
\subsection{Le modalità di bufferizzazione}
\label{sec:file_buffering}
+La bufferizzazione è una delle caratteristiche principali della
+interfaccia degli stream; lo scopo è quello di ridurre al minimo il
+numero di system call (\func{read} o \func{write}) eseguite nelle
+operazioni di input/output. Questa funzionalità è assicurata
+automaticamente dalla libreria, ma costituisce anche una degli aspetti
+più comunemente fraintesi, in particolare per quello che riguarda
+l'aspetto della scrittura dei dati sul file.
+
+I caratteri che vengono scritti su uno stream normalmente vengono
+accumulati in un buffer e poi trasmessi in blocco in maniera asincrona
+rispetto alla scrittura (quello che viene chiamato lo \textsl{scarico}
+dei dati, dall'inglese \textit{flush}) tutte le volte che il buffer
+viene riempito. Un comportamento analogo avviene anche in lettura (cioè
+dal file viene letto un blocco di dati, anche se se ne sono richiesti
+una quantità inferiore), ma la cosa ovviamente ha rilevanza inferiore,
+dato che i dati letti sono sempre gli stessi; in caso di scrittura
+invece, quando si ha un accesso contemporaneo allo stesso file (ad
+esempio da parte di un altro processo) si potranno vedere solo le parti
+effettivamente scritte, e non quelle ancora presenti nel buffer.
+
+Allo stesso modo, se si sta facendo dell'input/output interattivo
+bisognerà tenere presente le caratteristiche delle operazioni di scarico
+dei dati, poiché non è detto che ad una scrittura sullo stream
+corrisponda una immediata scrittura sul dispositivo.
+
+Per rispondere ad esigenze diverse, lo standard definisce tre distinte
+modalità in cui può essere eseguita la bufferizzazione, delle quali
+occorre essere ben consapevoli, specie in caso di lettura e scrittura da
+dispositivi interattivi:
+\begin{itemize}
+\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
+ caratteri vengono trasmessi direttamente al file non appena possibile
+ (effettuando immediatamente una \func{write}).
+\item \textit{line buffered}: in questo caso i caratteri vengono
+ normalmente trasmessi al file in blocco ogni volta che viene
+ incontrato un carattere di \textit{newline} (il carattere ASCII
+ \verb|\n|).
+\item \textit{fully buffered}: in questo caso i caratteri vengono
+ trasmessi da e verso il file in blocchi di dimensione opportuna.
+\end{itemize}
+
+Lo standard ANSI C specifica inoltre che lo standard output e lo
+standard input siano aperti in modalità \textit{fully buffered} quando
+non fanno riferimento ad un dispositivo interattivo, e che lo standard
+error non sia mai aperto in modalità \textit{fully buffered}.
+
+Linux, come BSD e SVr4, specifica il comportamento di default in maniera
+ancora più precisa, e cioè impone che lo standard error sia sempre
+\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
+rapidamente possibile) e che standard input e standard output siano aperti in
+modalità \textit{line buffered} quando sono associati ad un terminale (od
+altro dispositivo interattivo) ed in modalità \textit{fully buffered}
+altrimenti.
+
+Il comportamento specificato per standard input e standard output vale anche
+per tutti i nuovi stream aperti da un processo; la selezione comunque avviene
+automaticamente, e la libreria apre lo stream nella modalità più opportuna a
+seconda del file o del dispositivo scelto.
+
+La modalità \textit{line buffered} è quella che necessita di maggiori
+chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
+accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
+alla ricezione di un carattere di a capo; questo non è vero in tutti i casi,
+infatti, dato che le dimensioni del buffer usato dalle librerie sono fisse, se
+le si eccedono si può avere uno scarico dei dati anche prima che sia stato
+inviato un carattere di \textit{newline}.
+
+Un secondo punto da tenere presente, particolarmente quando si ha a che fare
+con I/O interattivo, è che quando si effettua una lettura su uno stream che
+comporta l'accesso al kernel\footnote{questo vuol dire sempre se lo stream da
+ cui si legge è in modalità \textit{unbuffered}.} viene anche eseguito lo
+scarico di tutti i buffer degli stream in scrittura.
+
+In \secref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
+opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
+dei dati.
+
+
\section{Funzioni base}
\label{sec:file_ansi_base_func}
Esamineremo in questa sezione le funzioni base dell'interfaccia degli stream,
-che provvedono le modalità per crearli, e le funzioni disponibili per leggere,
-scrivere e compiere le varie operazioni connesse all'uso dei file.
+analoghe a quelle di \secref{sec:file_base_func} per i file descriptor. In
+particolare vedremo come aprire, leggere, scrivere e cambiare la posizione
+corrente in uno stream.
-\subsection{Apertura di uno stream}
+\subsection{Apertura e chiusura di uno stream}
\label{sec:file_fopen}
+Le funzioni che si possono usare per aprire uno stream sono solo
+tre\footnote{\func{fopen} e \func{freopen} fanno parte dello standard
+ ANSI C, \func{fdopen} è parte dello standard POSIX.1.}, i loro
+prototipi sono:
+\begin{functions}
+ \headdecl{stdio.h}
+ \funcdecl{FILE * fopen(const char * path, const char *mode)}
+ Apre il file specificato da \param{path}.
+ \funcdecl{FILE * fdopen(int fildes, const char * mode)}
+ Associa uno stream al file descriptor \param{fildes}.
+ \funcdecl{FILE * freopen(const char * path, const char * mode, FILE *
+ stream)}
+ Apre il file specificato da \param{path} associandolo allo stream
+ specificato da \param{stream}, se questo è già aperto prima lo chiude.
+
+ \bodydesc{Le funzioni ritornano un puntatore valido in caso di
+ successo e \macro{NULL} in caso di errore, in tal caso \var{errno}
+ viene settata al valore ricevuto dalla funzione sottostante di cui è
+ fallita l'esecuzione.
+
+ Gli errori pertanto possono essere quelli di \func{malloc} per tutte
+ e tre le funzioni, quelli \func{open} per \func{fopen}, quelli di
+ \func{fcntl} per \func{fdopen} e quelli di \func{fopen},
+ \func{fclose} e \func{fflush} per \func{freopen}.}
+\end{functions}
+
+Normalmente la funzione che si usa per aprire uno stream è \func{fopen},
+essa apre il file specificato nella modalità specificata da
+\param{mode}, che è una stringa che deve iniziare con almeno uno dei
+valori indicati in \tabref{tab:file_fopen_mode} (sono possibili varie
+estensioni che vedremo in seguito).
+
+L'uso più comune di \func{freopen} è per redirigere uno dei tre file
+standard (vedi \secref{sec:file_std_stream}): il file \param{path} viene
+associato a \param{stream} e se questo è uno stream già aperto viene
+preventivamente chiuso.
+
+Infine \func{fdopen} viene usata per associare uno stream ad un file
+descriptor esistente ottenuto tramite una altra funzione (ad esempio con
+una \func{open}, una \func{dup}, o una \func{pipe}) e serve quando si
+vogliono usare gli stream con file come le fifo o i socket, che non
+possono essere aperti con le funzioni delle librerie standard del C.
+
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \texttt{r} & Il file viene aperto, l'accesso viene posto in sola
+ lettura, lo stream è posizionato all'inizio del file.\\
+ \texttt{r+} & Il file viene aperto, l'accesso viene posto in lettura e
+ scrittura, lo stream è posizionato all'inizio del file. \\
+% \hline
+ \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
+ creato se non esiste), l'accesso viene posto in sola scrittura, lo
+ stream è posizionato all'inizio del file.\\
+ \texttt{w+} & Il file viene aperto e troncato a lunghezza nulla (o
+ creato se non esiste), l'accesso viene posto in scrittura e lettura,
+ lo stream è posizionato all'inizio del file.\\
+% \hline
+ \texttt{a} & Il file viene aperto (o creato se non esiste) in
+ \textit{append mode}, l'accesso viene posto in sola scrittura. \\
+ \texttt{a+} & Il file viene aperto (o creato se non esiste) in
+ \textit{append mode}, l'accesso viene posto in lettura e scrittura. \\
+ \hline
+ \end{tabular}
+ \caption{Modalità di apertura di uno stream dello standard ANSI C che
+ sono sempre presenti in qualunque sistema POSIX}
+ \label{tab:file_fopen_mode}
+\end{table}
+
+In realtà lo standard ANSI C prevede un totale di 15 possibili valori
+diversi per \param{mode}, ma in \tabref{tab:file_fopen_mode} si sono
+riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
+il carattere \func{b} (come ultimo carattere o nel mezzo agli altri per
+le stringhe di due caratteri) che in altri sistemi operativi serve a
+distinguere i file binari dai file di testo; in un sistema POSIX questa
+distinzione non esiste e il valore viene accettato solo per
+compatibilità, ma non ha alcun effetto.
+
+Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
+indicate dopo aver specificato il \param{mode} con uno dei valori di
+\tabref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
+evitare di sovrascrivere un file già esistente (è analoga all'uso
+dell'opzione \macro{O\_EXCL} in \func{open}), se il file specificato già
+esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
+fallisce.
+
+Un'altra estensione serve a supportare la localizzazione, quando si
+aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
+valore \verb|STRING| è considerato il nome di una codifica dei caratteri
+e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
+opportune funzioni di conversione in lettura e scrittura.
+
+Inoltre nel caso si usi \func{fdopen} i valori specificati da
+\param{mode} devono essere compatibili con quelli con cui il file
+descriptor è stato aperto. Inoltre i modi \cmd{w} e \cmd{w+} non
+troncano il file. La posizione nello stream viene settata a quella
+corrente nel file descriptor, e le variabili di errore e di fine del
+file (vedi \secref{sec:file_io}) sono cancellate. Il file non viene
+duplicato e verrà chiuso alla chiusura dello stream.
+
+I nuovi file saranno creati secondo quanto visto in
+\secref{sec:file_ownership} ed avranno i permessi di accesso settati al
+valore \macro{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH}
+(pari a \macro{0666}) modificato secondo il valore di \acr{umask} per il
+processo (si veda \secref{sec:file_umask}).
+
+In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
+di messo una bufferizzazione; per questo motivo lo standard ANSI C
+richiede che ci sia una operazione di posizionamento fra una operazione
+di output ed una di input o viceversa (eccetto il caso in cui l'input ha
+incontrato la fine del file), altrimenti una lettura può ritornare anche
+il risultato di scritture precedenti l'ultima effettuata.
+
+Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
+una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
+\func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
+voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
+usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
+una operazione nominalmente nulla come \func{fseek(file, 0, SEEK\_CUR)} è
+sufficiente a garantire la sincronizzazione.
+
+Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione
+(vedi \secref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
+alcuna operazione di I/O sul file.
+
+Uno stream viene chiuso con la funzione \func{fclose} il cui prototipo è:
+\begin{prototype}{stdio.h}{int fclose(FILE * stream)}
+ Chiude lo stream \param{stream}.
+
+ Restituisce 0 in caso di successo e \macro{EOF} in caso di errore, nel qual
+ caso setta \var{errno} a \macro{EBADF} se il file descriptor indicato da
+ \param{stream} non è valido, o uno dei valori specificati dalla sottostante
+ funzione che è fallita (\func{close}, \func{write} o \func{fflush}).
+\end{prototype}
+
+La funzione effettua uno scarico di tutti i dati presenti nei buffer di
+uscita e scarta tutti i dati in ingresso, se era stato allocato un
+buffer per lo stream questo verrà rilasciato. La funzione effettua lo
+scarico solo per i dati presenti nei buffer in user space usati dalle
+\acr{glibc}; se si vuole essere sicuri che il kernel forzi la scrittura
+su disco occorrerà effettuare una \func{sync}.
+
+Linux supporta, come estensione implementata dalle \acr{glibc}, anche una
+altra funzione, \func{fcloseall}, che serve a chiudere tutti i file, il suo
+prototipo è:
+\begin{prototype}{stdio.h}{int fcloseall(void)}
+ Chiude tutti gli stream.
+
+ Restituisce 0 se non ci sono errori ed \macro{EOF} altrimenti.
+\end{prototype}
+la funzione esegue lo scarico dei dati bufferizzati in uscita e scarta quelli
+in ingresso, chiudendo tutti i file. Questa funzione è provvista solo per i
+casi di emergenza, quando si è verificato un errore ed il programma deve
+essere abortito, ma si vuole compiere qualche altra operazione dopo aver
+chiuso i file e prima di uscire (si ricordi quanto visto in
+\secref{sec:proc_exit}).
+
\subsection{Lettura e scrittura su uno stream}
\label{sec:file_io}
-
-\subsection{Posizionamento su uno stream}
-\label{sec:file_fseek}
+Una delle caratteristiche più utili dell'interfaccia degli stream è la
+ricchezza delle funzioni disponibili per le operazioni di lettura e
+scrittura sui file. Sono infatti previste ben tre diverse modalità
+modalità di input/output non formattato:
+\begin{enumerate*}
+\item\textsl{binario} in cui legge/scrive un blocco di dati alla
+ volta, vedi \secref{sec:file_binary_io}.
+\item\textsl{a caratteri} in cui si legge/scrive un carattere alla
+ volta (con la bufferizzazione gestita automaticamente dalla libreria),
+ vedi \secref{sec:file_char_io}.
+\item\textsl{di linea} in cui si legge/scrive una linea (terminata dal
+ carattere di newline \verb|\n|) alla volta, vedi
+ \secref{sec:file_line_io}.
+\end{enumerate*}
+ed inoltre la modalità di input/output formattato.
+
+A differenza dell'interfaccia dei file descriptor, con gli stream il
+raggiungimento della fine del file è considerato un errore, e viene
+notificato come tale dai valori di uscita delle varie funzioni. Nella
+maggior parte dei casi questo avviene con la restituzione del valore
+intero (di tipo \type{int}) \macro{EOF}\footnote{la costante deve essere
+ negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
+ valori diversi.} definito anch'esso nell'header \func{stdlib.h}.
+
+Dato che le funzioni dell'interfaccia degli stream sono funzioni di libreria
+che si appoggiano a delle system call, esse non settano direttamente la
+variabile \var{errno}, che mantiene il valore settato dalla system call che ha
+riportato l'errore.
+
+Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
+il problema di come distinguerla da un errore effettivo; basarsi solo sul
+valore di ritorno della funzione e controllare il valore di \var{errno}
+infatti non basta, dato che quest'ultimo potrebbe essere stato settato in una
+altra occasione, (si veda \secref{sec:sys_errno} per i dettagli del
+funzionamento di \var{errno}).
+
+Per questo motivo tutte le implementazioni delle librerie standard
+mantengono per ogni stream almeno due flag all'interno dell'oggetto
+\type{FILE}, il flag di \textit{end-of-file}, che segnala che si è
+raggiunta la fine del file in lettura, e quello di errore, che segnala
+la presenza di un qualche errore nelle operazioni di input/output;
+questi due flag possono essere riletti dalle funzioni:
+\begin{functions}
+ \headdecl{stdio.h}
+ \funcdecl{int feof(FILE *stream)}
+ Controlla il flag di end-of-file di \param{stream}.
+ \funcdecl{int ferror(FILE *stream)}
+ Controlla il flag di errore di \param{stream}.
+
+ Entrambe le funzioni ritornano un valore diverso da zero se i relativi
+ flag sono settati.
+\end{functions}
+\noindent si tenga presente comunque che la lettura di questi flag segnala
+soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
+qualunque operazione sullo stream, il controllo quindi deve essere effettuato
+ogni volta che si chiama una funzione di libreria.
+
+Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
+la funzione \func{clearerr}, il cui prototipo è:
+\begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
+ Cancella i flag di errore ed end-of-file di \param{stream}.
+\end{prototype}
+\noindent in genere si usa questa funziona una volta che si sia identificata e
+corretta la causa di un errore per evitare di mantenere i flag attivi,
+così da poter rilevare una successiva ulteriore condizione di errore.
\subsection{Input/output binario}
\label{sec:file_binary_io}
+La prima modalità di input/output non formattato ricalca quella della
+interfaccia dei file descriptor, e provvede semplicemente la scrittura e
+la lettura dei dati da un buffer verso un file e viceversa. In generale
+questa è la modalità che si usa quando si ha a che fare con dati non
+formattati. Le due funzioni che si usano per l'I/O binario sono:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{size\_t fread(void * ptr, size\_t size, size\_t nmemb, FILE
+ * stream)}
+
+ \funcdecl{size\_t fwrite(const void * ptr, size\_t size, size\_t
+ nmemb, FILE * stream)}
+
+ Le funzioni rispettivamente leggono e scrivono \param{nmemb} elementi
+ di dimensione \param{size} dal buffer \param{ptr} al file
+ \param{stream}.
+
+ Entrambe le funzioni ritornano il numero di elementi letti o scritti,
+ in caso di errore o fine del file viene restituito un numero di
+ elementi inferiore al richiesto.
+\end{functions}
+
+In genere si usano queste funzioni quando si devono trasferire su file
+blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
+tipico è quello in cui si salva un vettore (o un certo numero dei suoi
+elementi) con una chiamata del tipo:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+int WriteVect(FILE * stream, double * vec, size_t nelem)
+{
+ int size, nread;
+ size = sizeof(*vec);
+ if ( (nread = fwrite(vec, size, nelem, stream)) != nelem) {
+ perror("Write error");
+ }
+ return nread;
+}
+\end{lstlisting}
+in questo caso devono essere specificate le dimensioni di ciascun
+elemento ed il numero di quelli che si vogliono scrivere. Un secondo
+caso è invece quello in cui si vuole trasferire su file una struttura;
+si avrà allora una chiamata tipo:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct histogram {
+ int nbins;
+ double max, min;
+ double * bin;
+} histo;
+
+int WriteStruct(FILE * stream, struct histogram * histo, size_t nelem)
+{
+ if ( fwrite(vec, sizeof(*histo), 1, stream) !=1) {
+ perror("Write error");
+ }
+ return nread;
+}
+\end{lstlisting}
+in cui si specifica la dimensione dell'intera struttura ed un solo
+elemento.
+
+In realtà quello che conta nel trasferimento dei dati sono le dimensioni
+totali, che sono sempre pari al prodotto \func{size * nelem}; la sola
+differenza è che le funzioni non ritornano il numero di byte scritti,
+ma il numero di elementi.
+
+La funzione \func{fread} legge sempre un numero intero di elementi, se
+incontra la fine del file l'oggetto letto parzialmente viene scartato
+(lo stesso avviene in caso di errore). In questo caso la posizione dello
+stream viene settata alla fine del file (e non a quella corrispondente
+alla quantità di dati letti).
+
+In caso di errore (o fine del file per \func{fread}) entrambe le
+funzioni restituiscono il numero di oggetti effettivamente letti o
+scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
+avviene per i file descriptor, questo segnala una condizione di errore e
+occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
+problema.
+
+Benché queste funzioni assicurino la massima efficienza per il
+salvataggio dei dati, i dati memorizzati attraverso di esse presentano
+lo svantaggio di dipendere strettamente dalla piattaforma di sviluppo
+usata ed in genere possono essere riletti senza problemi solo dallo
+stesso programma che li ha prodotti.
+
+Infatti diversi compilatori possono eseguire ottimizzazioni diverse
+delle strutture dati e alcuni compilatori (come il \cmd{gcc}) possono
+anche scegliere se ottimizzare l'occupazione di spazio, impacchettando
+più strettamente i dati, o la velocità inserendo opportuni
+\textit{padding} per l'allineamento dei medesimi generando quindi output
+binari diversi. Inoltre altre incompatibilità si possono presentare
+quando entrano in gioco differenze di architettura hardware, come la
+dimensione del bus o la modalità di ordinamento dei bit o il formato
+delle variabili in floating point.
+
+Per questo motivo quando si usa l'input/output binario occorre sempre
+essere prendere le opportune precauzioni (in genere usare un formato di
+più alto livello che permetta di recuperare l'informazione completa),
+per assicurarsi che versioni diverse del programma siano in grado di
+rileggere i dati tenendo conto delle eventuali differenze.
+
+Le \acr{glibc} definiscono altre due funzioni per l'I/O binario, che
+evitano il lock implicito dello stream, usato per dalla librerie per la
+gestione delle applicazioni multi-thread (si veda
+\secref{sec:file_stream_thread} per i dettagli).
+
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{size\_t fread\_unlocked(void * ptr, size\_t size, size\_t
+ nmemb, FILE * stream)}
+
+ \funcdecl{size\_t fwrite\_unlocked(const void * ptr, size\_t size,
+ size\_t nmemb, FILE * stream)}
+
+ Le funzioni sono identiche alle analoghe \func{fread} e \func{fwrite}
+ ma non acquisiscono il lock implicito sullo stream.
+\end{functions}
+\noindent entrambe le funzioni sono estensioni GNU previste solo dalle
+\acr{glibc}.
+
+
+\subsection{Input/output a caratteri}
+\label{sec:file_char_io}
+
+La seconda modalità di input/output è quella a caratteri, in cui si
+trasferisce un carattere alla volta. Le funzioni per la lettura a
+caratteri sono tre, \func{fgetc}, \func{getc} e \func{getchar}, i
+rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{int getc(FILE *stream)} Legge un byte da \param{stream} e lo
+ restituisce come intero. In genere è implementata come una macro.
+
+ \funcdecl{int fgetc(FILE *stream)} Legge un byte da \param{stream} e lo
+ restituisce come intero. È una sempre una funzione.
+
+ \funcdecl{int getchar(void)} è equivalente a \func{getc(stdin)}.
+
+ \bodydesc{Tutte queste funzioni leggono un byte alla volta, che viene
+ restituito come intero; in caso di errore o fine del file il valore
+ di ritorno è \macro{EOF}.}
+\end{functions}
+
+A parte \func{getchar}, che si usa in genere per leggere un carattere da
+tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
+differenza è che \func{gets} è ottimizzata al massimo e normalmente
+viene implementata con una macro, per cui occorre stare attenti a cosa
+le si passa come argomento, infatti \param{stream} può essere valutato
+più volte nell'esecuzione, e non viene passato in copia con il
+meccanismo visto in \secref{sec:proc_var_passing}; per questo motivo se
+si passa una espressione si possono avere effetti indesiderati.
+
+Invece \func{fgets} è assicurata essere sempre una funzione, per questo
+motivo la sua esecuzione normalmente è più lenta per via dell'overhead
+della chiamata, ma è altresì possibile ricavarne l'indirizzo, che può
+essere passato come parametro ad un altra funzione (e non si hanno i
+problemi accennati in precedenza con \param{stream}).
+
+Le tre funzioni restituiscono tutte un \type{unsigned char} convertito
+ad \type{int} (si usa \type{unsigned char} in modo da evitare
+l'espansione del segno). In questo modo il valore di ritorno è sempre
+positivo, tranne in caso di errore o fine del file.
+
+Nelle estenzioni GNU che provvedono la localizzazione sono definite tre
+funzioni equivalenti alle precedenti che invece di un carattere di un
+byte restituiscono un carattere in formato esteso (cioè di tipo
+\type{wint\_t}, il loro prototipo è:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{wint\_t getwc(FILE *stream)} Legge un carattere esteso da
+ \param{stream}. In genere è implementata come una macro.
+
+ \funcdecl{wint\_t fgetwc(FILE *stream)} Legge un carattere esteso da
+ \param{stream} È una sempre una funzione.
+
+ \funcdecl{wint\_t getwchar(void)} è equivalente a \func{getwc(stdin)}.
+
+ \bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
+ caso di errore o fine del file il valore di ritorno è \macro{WEOF}.}
+\end{functions}
+
+Per scrivere un carattere si possono usare tre funzioni analoghe alle
+precedenti usate per leggere: \func{putc}, \func{fputc} e
+\func{putchar}; i loro prototipi sono:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{int putc(int c, FILE *stream)} Scrive il carattere \param{c}
+ su \param{stream}. In genere è implementata come una macro.
+
+ \funcdecl{int fputc(FILE *stream)} Scrive il carattere \param{c} su
+ \param{stream}. È una sempre una funzione.
+
+ \funcdecl{int putchar(void)} è equivalente a \func{putc(stdin)}.
+
+ \bodydesc{Le funzioni scrivono sempre un carattere alla volta, il cui
+ valore viene restituito in caso di successo; in caso di errore o
+ fine del file il valore di ritorno è \macro{EOF}.}
+\end{functions}
+
+Tutte queste funzioni scrivono sempre un byte alla volta, anche se
+prendono come parametro un \type{int} (che pertanto deve essere ottenuto
+con un cast da un \type{unsigned char}). Anche il valore di ritorno è
+sempre un intero; in caso di errore o fine del file il valore di ritorno
+è \macro{EOF}.
+
+Come nel caso dell'I/O binario le \acr{glibc} provvedono per ciascuna
+delle funzioni precedenti una seconda funzione, il cui nome è ottenuto
+aggiungendo un \func{\_unlocked}, che esegue esattamente le stesse
+operazioni evitando però il lock implicito dello stream.
+
+Per compatibilità con SVID sono provviste anche due funzioni per leggere
+e scrivere una \textit{word} (che è sempre definita come \type{int}); i
+loro prototipi sono:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{int getw(FILE *stream)} Legge una parola da \param{stream}.
+ \funcdecl{int putw(int w, FILE *stream)} Scrive la parola \param{w} su
+ \param{stream}.
+
+ \bodydesc{Le funzioni restituiscono la parola \param{w}, o \macro{EOF}
+ in caso di errore o di fine del file.}
+\end{functions}
+\noindent l'uso di queste funzioni è deprecato in favore dell'uso di
+\func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
+valore -1 da una condizione di errore che restituisce \macro{EOF}.
+
+Una degli usi più frequenti dell'input/output a caratteri è nei
+programmi di \textit{parsing} in cui si analizza il testo; in questo
+contesto diventa utile poter analizzare il carattere successivo da uno
+stream senza estrarlo effettivamente (la tecnica è detta \textit{peeking
+ ahead}) in modo che il programma possa regolarsi sulla base avendo
+dato una \textsl{sbirciatina} a quello che viene dopo.
+
+Nel nostro caso questo tipo di comportamento può essere realizzato prima
+leggendo il carattere, e poi rimandandolo indietro, cosicchè ridiventi
+disponibile per una lettura successiva; la funzione che inverte la
+lettura si chiama \func{ungetc} ed il suo prototipo è:
+\begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
+ Cancella i flag di errore ed end-of-file di \param{stream}.
+\end{prototype}
+
+
+
+
\subsection{Input/output di linea}
\label{sec:file_line_io}
+La terza ed ultima modalità di input/output non formattato è quello di
+linea, in cui legge o scrive una riga alla volta; questa è una modalità
+molto usata, ma che presenta le caratteristiche più controverse.
+
+Le funzioni per leggere una linea sono sostazialmente due, \func{gets} e
+\func{fgets}, i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{char * gets(char * string)} Scrive su \param{string} una
+ linea letta da \var{stdin}.
+
+ \funcdecl{char * fgets(char * string, int size, FILE *stream)}
+ Scrive su \param{string} la linea letta da \param{stream} per un
+ massimo di \param{size} byte.
+
+ \bodydesc{Le funzioni restituiscono della stringa letta o \macro{NULL}
+ in caso di errore.}
+\end{functions}
+
+
\subsection{Input/output formattato}
\label{sec:file_formatted_io}
-\subsection{Chiusura di uno stream}
-\label{sec:file_fclose}
+\subsection{Posizionamento su uno stream}
+\label{sec:file_fseek}
+
\section{Funzioni avanzate}
\label{sec:file_stream_adv_func}
+In questa sezione esamineremo le funzioni che permettono di controllare
+alcune caratteristiche più particolari degli stream, come la lettura
+degli attributi, le modalità di bufferizzazione, etc.
+
+
+\subsection{Le funzioni di controllo}
+\label{sec:file_stream_cntrl}
+
+Al contrario di quanto avviene con i file descriptor le librerie standard del
+C non prevedono nessuna funzione come la \func{fcntl} per la lettura degli
+attributi degli stream; le \acr{glibc} però supportano alcune estensioni
+derivate da Solaris, che permettono di ottenere informazioni utili.
+
+In certi casi può essere necessario sapere se un certo stream è accessibile in
+lettura o scrittura. In genere questa informazione non è disponibile, e si
+deve ricordare come il file è stato aperto. La cosa può essere complessa se le
+operazioni vengono effettuate in una subroutine, che a questo punto
+necessiterà di informazioni aggiuntive rispetto al semplice puntatore allo
+stream; questo può essere evitato con le due funzioni \func{\_\_freadable} e
+\func{\_\_fwritable} i cui prototipi sono:
+\begin{functions}
+ \headdecl{stdio\_ext.h}
+ \funcdecl{int \_\_freadable (FILE * stream)}
+ Restituisce un valore diverso da zero se \param{stream} consente la lettura.
+
+ \funcdecl{int \_\_fwritable(FILE * stream)}
+ Restituisce un valore diverso da zero se \param{stream} consente la
+ scrittura.
+\end{functions}
+
+Altre due funzioni, \func{\_\_freading} e \func{\_\_fwriting} servono ad un
+uso ancora più specialistico, il loro prototipo è:
+\begin{functions}
+ \headdecl{stdio\_ext.h}
+ \funcdecl{int \_\_freading (FILE * stream)}
+ Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+ lettura o se l'ultima operazione è stata di lettura.
+
+ \funcdecl{int \_\_fwriting(FILE * stream)}
+ Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+ scrittura o se l'ultima operazione è stata di scrittura.
+\end{functions}
+
+Le due funzioni hanno lo scopo di determinare di che tipo è stata l'ultima
+operazione eseguita su uno stream aperto in lettura/scrittura; ovviamente se
+uno stream è aperto in sola lettura (o sola scrittura) la modalità dell'ultima
+operazione è sempre determinata; l'unica ambiguità è quando non sono state
+ancora eseguite operazioni, in questo caso le funzioni rispondono come se
+una operazione ci fosse comunque stata.
+
+La conoscenza dell'ultima operazione effettuata su uno stream aperto in
+lettura/scrittura è utile in quanto permette di trarre conclusioni sullo stato
+del buffer e del suo contenuto.
+
\subsection{Il controllo della bufferizzazione}
-\label{sec:file_buffering-ctrl}
+\label{sec:file_buffering_ctrl}
+Come accennato in \secref{sec:file_buffering} le librerie definiscono una
+serie di funzioni che permettono di controllare il comportamento degli
+stream; se non si è
-\subsection{Dettagli dell'implementazione}
-\label{sec:file_stream_details}
+\subsection{Gli stream e i thread}
+\label{sec:file_stream_thread}
-\subsection{File temporanei}
-\label{sec:file_temp_file}
+Gli stream possono essere usati in applicazioni multi-thread allo stesso
+modo in cui sono usati nelle applicazioni normali, ma si deve essere
+consapovoli delle possibili complicazioni anche quando non si usano i
+thread, dato che l'implementazione delle librerie è influenzata
+pesantemente dalle richieste necessarie per garantirne l'uso coi thread.
-\subsection{Efficienza}
-\label{sec:file_stream_efficiency}
-
+\begin{functions}
+ \headdecl{stdio.h}
+
+ \funcdecl{void flockfile(FILE * stream)} Esegue l'acquisizione del
+ lock dello stream \param{stream}, bloccandosi in caso il lock non
+ disponibile.
+
+ \funcdecl{int ftrylockfile(FILE * stream)} Tenta l'acquisizione del
+ lock dello stream \param{stream}, senza bloccarsi in caso il lock non sia
+ disponibile. Ritorna zero in caso di acquisizione del lock, diverso da
+ zero altrimenti.
+
+ \funcdecl{void funlockfile(FILE * stream)} Rilascia il lock dello
+ stream \param{stream}.
+\end{functions}
+\subsection{Dettagli dell'implementazione}
+\label{sec:file_stream_details}
+\subsection{File temporanei}
+\label{sec:file_temp_file}
+\subsection{Efficienza}
+\label{sec:file_stream_efficiency}
projects / gapil.git / blobdiff