Per poter accedere al contenuto di un file occorre creare un canale di
comunicazione con il kernel che renda possibile operare su di esso. Questo si
-fa aprendo il file con la funzione \func{open} (vedi sez.~\ref{sec:file_open})
-che provvederà a localizzare \itindex{inode} l'inode del file e inizializzare
-i puntatori che rendono disponibili le funzioni che il
-\itindex{Virtual~File~System} VFS mette a disposizione (quelle di
-tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
-file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
-impedendo ogni ulteriore operazione.
+fa aprendo il file con la funzione \func{open} (vedi
+sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
+l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
+le funzioni che il \itindex{Virtual~File~System} VFS mette a disposizione
+(quelle di tab.~\ref{tab:file_file_operations}). Una volta terminate le
+operazioni, il file dovrà essere chiuso, e questo chiuderà il canale di
+comunicazione impedendo ogni ulteriore operazione.
All'interno di ogni processo i file aperti sono identificati da un numero
intero non negativo, che viene chiamato \textit{file descriptor}. Quando un
-\subsection{Apertura e creazione di un file}
-\label{sec:file_open}
+\subsection{Apertura, creazione e chiusura di un file}
+\label{sec:file_open_close}
La funzione di sistema \funcd{open} è la principale funzione dell'interfaccia
di gestione dei file, quella che dato un \textit{pathname} consente di
\const{O\_CREAT}, o non esiste un suo componente.
\item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
\param{pathname} non è una directory.
- \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
+ \item[\errcode{ENXIO}] si sono impostati \const{O\_NONBLOCK} o
\const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
processo o \param{pathname} è un file di dispositivo ma il dispositivo è
assente.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
di un programma in esecuzione.
\item[\errcode{EWOULDBLOCK}] la funzione si sarebbe bloccata ma si è
- richiesto \const{O\_NOBLOCK}.
+ richiesto \const{O\_NONBLOCK}.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EMFILE},
\errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM}, \errval{ENOSPC},
Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
altro processo (torneremo sul significato della condivisione dei file
descriptor, che in genere si ottiene dopo una \func{fork}, in
-sez.~\ref{sec:file_sharing}) ed è impostato, come accennato in
+sez.~\ref{sec:file_shared_access}) ed è impostato, come accennato in
sez.~\ref{sec:proc_exec}, per restare aperto attraverso una
\func{exec}. Inoltre la posizione sul file, il cosiddetto \textit{offset}, è
impostata all'inizio del file. Una volta aperto un file si potrà operare su di
Ciascun flag viene identificato da una apposita costante, ed il valore
di \param{flags} deve essere specificato come OR aritmetico di queste
-costanti. I vari bit che si possono usare come componenti di \param{flags}
-sono divisi in tre gruppi principali. Il primo gruppo è quello dei cosiddetti
-flag delle \textsl{modalità di accesso} (o \textit{access mode flags}), che
-specificano che tipo di accesso si effettuerà sul file, fra lettura, scrittura
-e lettura/scrittura. Questa modalità deve essere indicata usando una delle
+costanti. Inoltre per evitare problemi di compatibilità con funzionalità che
+non sono previste o non ancora supportate in versioni meno recenti del kernel,
+la \func{open} di Linux ignora i flag che non riconosce, pertanto
+l'indicazione di un flag inesistente non provoca una condizione di errore.
+
+I vari bit che si possono usare come componenti di \param{flags} sono divisi
+in tre gruppi principali. Il primo gruppo è quello dei cosiddetti flag delle
+\textsl{modalità di accesso} (o \textit{access mode flags}), che specificano
+che tipo di accesso si effettuerà sul file, fra lettura, scrittura e
+lettura/scrittura. Questa modalità deve essere indicata usando una delle
costanti di tab.~\ref{tab:open_access_mode_flag}.
\begin{table}[htb]
si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
\textit{modification time} e lo \textit{status change time}.
-\begin{table}[htb]
+\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|p{10 cm}|}
tutte le volte che il file è pronto per le
operazioni di lettura o scrittura. Questo flag si
può usare solo terminali, pseudo-terminali e socket
- e, a partire dal kernel 2.6, anche sulle fifo.\\
+ e, a partire dal kernel 2.6, anche sulle fifo. Per
+ un bug dell'implementazione non è opportuno usarlo
+ in fase di apertura del file, deve
+ invece essere attivato successivamente con
+ \func{fcntl}.\\
\const{O\_CLOEXEC}& Attiva la modalità di \itindex{close-on-exec}
\textit{close-on-exec} (vedi
sez.~\ref{sec:proc_exec}) sul file. Il flag è
file (vedi sez.~\ref{sec:file_file_times}). Per
molti filesystem questa funzionalità non è
disponibile per il singolo file ma come opzione
- generale da specificare in fase di montaggio.\\
+ generale da specificare in fase di
+ montaggio. Introdotto con il kernel 2.6.8 ed
+ utilizzabile soltanto se si è definita la
+ macro \macro{\_GNU\_SOURCE}.\\
\const{O\_NONBLOCK}& Apre il file in \textsl{modalità non bloccante} per
le operazioni di I/O (vedi
sez.~\ref{sec:file_noblocking}). Questo significa
\var{f\_flags} della struttura \kstruct{file} insieme al valore della
\textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
status flags}. Il loro valore viene impostato alla chiamata di \func{open},
-ma possono essere riletti ed in alcuni di essi anche modificati, con
-conseguente effetto sulle caratteristiche operative che controllano, con
-\func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
+ma possono venire riletti in un secondo tempo con \func{fcntl}, inoltre alcuni
+di essi possono anche essere modificati tramite questa funzione, con
+conseguente effetto sulle caratteristiche operative che controllano (torneremo
+sull'argomento in sez.~\ref{sec:file_fcntl}).
+
+Il flag \const{O\_ASYNC} (che, per per compatibilità con BSD, si può indicare
+anche con la costante \const{FASYNC}) è definito come possibile valore per
+\func{open}, ma per un bug dell'implementazione,\footnote{segnalato come
+ ancora presente nella pagina di manuale almeno fino al Settembre 2011.} non
+solo non attiva il comportamento citato, ma se usato richiede di essere
+esplicitamente disattivato prima di essere attivato in maniera effettiva con
+l'uso di \func{fcntl}. Per questo motivo, non essendovi nessuna necessità
+specifica di definirlo in fase di apertura del file, è sempre opportuno
+attivarlo in un secondo tempo con \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl}).
Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
\textit{user space} da cui si effettua il trasferimento diretto dei dati siano
allineati alle dimensioni dei blocchi del filesystem. Con il kernel 2.6 in
genere basta che siano allineati a multipli di 512 byte, ma le restrizioni
-possono variare a seconda del filesystem, ed inoltre su alcuni filesystem può
-non essere supportato, nel qual caso si avrà un errore di \errval{EINVAL}.
+possono variare a seconda del filesystem, ed inoltre su alcuni filesystem
+questo flag può non essere supportato, nel qual caso si avrà un errore di
+\errval{EINVAL}.
Lo scopo di \const{O\_DIRECT} è consentire un completo controllo sulla
bufferizzazione dei propri dati per quelle applicazioni (in genere database)
un peggioramento delle prestazioni. Lo stesso dicasi per l'interazione con
eventuale mappatura in memoria del file (vedi sez.~\ref{sec:file_memory_map}).
-Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta
-sostanzialmente solo una scrittura sincrona dei dati dei buffer in
-\textit{user space}, questo non è completamente equivalente all'uso di
-\const{O\_SYNC} che garantisce anche sulla scrittura sincrona dei metadati
-associati alla scrittura dei dati del file. Per questo in genere è opportuno
-se si usa \const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
+Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta una
+scrittura sincrona dei dati dei buffer in \textit{user space}, questo non è
+completamente equivalente all'uso di \const{O\_SYNC} che garantisce anche
+sulla scrittura sincrona dei metadati associati alla scrittura dei dati del
+file.\footnote{la situazione si complica ulteriormente per NFS, in cui l'uso
+ del flag disabilita la bufferizzazione solo dal lato del client, e può
+ causare problemi di prestazioni.} Per questo in genere è opportuno se si usa
+\const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
differisce da quanto previsto dallo standard POSIX.1 che prevede, oltre a
questo flag che dovrebbe indicare la sincronizzazione completa di tutti i dati
-e di tutti i metadati, altri due flag \const{O\_DSYNC} e \const{O\_RSYNC}. Il
-primo dei due richiede la scrittura sincrona di tutti i dati del file e dei
+e di tutti i metadati, altri due flag \const{O\_DSYNC} e \const{O\_RSYNC}.
+
+Il primo dei due richiede la scrittura sincrona di tutti i dati del file e dei
metadati che ne consentono l'immediata rilettura, ma non di tutti i metadati,
per evitare la perdita di prestazioni relativa alla sincronizzazione di
-informazioni ausiliarie come i tempi dei file.
-
-Il secondo, da usare in combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne
-sospende l'effetto, consentendo al kernel di bufferizzare le scritture, ma
-soltanto finché non avviene una lettura, in quel caso i dati ed i metadati
-dovranno essere sincronizzati immediatamente (secondo le modalità indicate da
-\const{O\_SYNC} e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che
-detta sincronizzazione non sia completata.
+informazioni ausiliarie come i tempi dei file. Il secondo, da usare in
+combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne sospende l'effetto,
+consentendo al kernel di bufferizzare le scritture, ma soltanto finché non
+avviene una lettura, in quel caso i dati ed i metadati dovranno essere
+sincronizzati immediatamente (secondo le modalità indicate da \const{O\_SYNC}
+e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che detta
+sincronizzazione non sia completata.
Nel caso di Linux, fino al kernel 2.6.33, esisteva solo \const{O\_SYNC}, ma
con il comportamento previsto dallo standard per \const{O\_DSYNC}, e sia
sinonimi di \const{O\_SYNC}. Con il kernel 2.6.33 il significato di
\const{O\_SYNC} è diventato quello dello standard, ma gli è stato assegnato un
valore diverso, mantenendo quello originario, con il comportamento
-corrispondete, per \const{O\_DSYNC}.
+corrispondete, per \const{O\_DSYNC} in modo che applicazioni compilate con
+versioni precedenti delle librerie e del kernel non trovassero un
+comportamento diverso. Inoltre il nuovo \const{O\_SYNC} è stato definito in
+maniera opportuna in modo che su versioni del kernel precedenti la 2.6.33
+torni a corrispondere al valore di \const{O\_DSYNC}.
% NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
O\_CREAT|O\_WRONLY|O\_TRUNC, mode)} e resta solo per compatibilità con i
vecchi programmi.
-
-\subsection{La funzione \func{close}}
-\label{sec:file_close}
-
Una volta che l'accesso ad un file non sia più necessario la funzione di
sistema \funcd{close} permette di ``\textsl{chiuderlo}'', in questo modo il
file non sarà più accessibile ed il relativo file descriptor ritornerà
ed inoltre \errval{EIO} nel suo significato generico.}
\end{funcproto}
-La funzione chiude il file descriptor \param{fd}, la chiusura rilascia ogni
-blocco (il \textit{file locking} \itindex{file~locking} è trattato in
-sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
+La funzione chiude il file descriptor \param{fd}. La chiusura rilascia ogni
+eventuale blocco (il \textit{file locking} \itindex{file~locking} è trattato
+in sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
esso. Se \param{fd} è l'ultimo riferimento (di eventuali copie, vedi
-sez.~\ref{sec:file_sharing} e \ref{sec:file_dup}) ad un file aperto, tutte le
-risorse nella \itindex{file~table} \textit{file table} vengono
+sez.~\ref{sec:file_shared_access} e \ref{sec:file_dup}) ad un file aperto,
+tutte le risorse nella \itindex{file~table} \textit{file table} vengono
rilasciate. Infine se il file descriptor era l'ultimo riferimento ad un file
su disco quest'ultimo viene cancellato.
ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
\func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
\emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
-comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
-dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
-di ripetere tre volte il comando prima di eseguire lo shutdown).
+comportamento dell'hardware, che a sua volta può introdurre ottimizzazioni
+dell'accesso al disco che ritardano la scrittura dei dati. Da questo deriva
+l'abitudine di alcuni sistemisti di ripetere tre volte il comando omonimo
+prima di eseguire lo shutdown di una macchina.
\subsection{La gestione della posizione nel file}
In genere, a meno di non avere richiesto la modalità \itindex{append~mode} di
\textit{append} con \const{O\_APPEND}, questa posizione viene impostata a zero
all'apertura del file. È possibile impostarla ad un valore qualsiasi con la
-funzione si sistema \funcd{lseek}, il cui prototipo è:
+funzione di sistema \funcd{lseek}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{unistd.h}
\fdecl{off\_t lseek(int fd, off\_t offset, int whence)}
-\fdesc{Imposta la posizione sul file..}
+\fdesc{Imposta la posizione sul file.}
}
{La funzione ritorna il valore della posizione sul file in caso di successo e
ed inoltre \errval{EBADF} nel suo significato generico.}
\end{funcproto}
-La funzione imposta la nuova posizione sul file usando il valore specificato
+La funzione imposta la nuova posizione sul file usando il valore indicato
da \param{offset}, che viene sommato al riferimento dato
-dall'argomento \param{whence}. Quest'ultimo deve essere indicato con una delle
-costanti riportate in tab.~\ref{tab:lseek_whence_values}.\footnote{per
- compatibilità con alcune vecchie notazioni questi valori possono essere
- rimpiazzati rispettivamente con 0, 1 e 2 o con \const{L\_SET},
- \const{L\_INCR} e \const{L\_XTND}.}
+dall'argomento \param{whence}, che deve essere indicato con una delle costanti
+riportate in tab.~\ref{tab:lseek_whence_values}.\footnote{per compatibilità
+ con alcune vecchie notazioni questi valori possono essere rimpiazzati
+ rispettivamente con 0, 1 e 2 o con \const{L\_SET}, \const{L\_INCR} e
+ \const{L\_XTND}.} Si tenga presente che la chiamata a \func{lseek} non causa
+nessun accesso al file, si limita a modificare la posizione corrente (cioè il
+campo \var{f\_pos} della struttura \kstruct{file}, vedi
+fig.~\ref{fig:file_proc_file}). Dato che la funzione ritorna la nuova
+posizione, usando il valore zero per \param{offset} si può riottenere la
+posizione corrente nel file con \code{lseek(fd, 0, SEEK\_CUR)}.
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|p{10cm}|}
\hline
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
\const{SEEK\_DATA}& Sposta la posizione nel file sull'inizio del primo
blocco di dati dopo un \textit{hole} che segue (o
- coincide) con la posizione indicata da \param{offset}.\\
+ coincide) con la posizione indicata da \param{offset}
+ (dal kernel 3.1).\\
\const{SEEK\_HOLE}& Sposta la posizione sul file all'inizio del primo
\textit{hole} nel file che segue o inizia
- con \param{offset}, oppure \param{offset} se questo è
- all'interno di un \textit{hole} o alla fine del file
- se non ci sono \textit{hole} dopo \param{offset}.\\
+ con \param{offset}, oppure si porta su \param{offset}
+ se questo è all'interno di un \textit{hole}, oppure si
+ porta alla fine del file se non ci sono \textit{hole}
+ dopo \param{offset} (dal kernel 3.1).\\
\hline
- \end{tabular}
- \caption{Possibili valori per l'argomento \param{whence} di \func{lseek}.}
+ \end{tabular} \caption{Possibili valori per l'argomento \param{whence} di
+ \func{lseek}.}
\label{tab:lseek_whence_values}
\end{table}
% NOTE: per SEEK_HOLE e SEEK_DATA, inclusi nel kernel 3.1, vedi
% http://lwn.net/Articles/439623/
-Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
-file, si limita a modificare la posizione corrente (cioè il campo \var{f\_pos}
-della struttura \kstruct{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che
-la funzione ritorna la nuova posizione, usando il valore zero
-per \param{offset} si può riottenere la posizione corrente nel file chiamando
-la funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
-
Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
la successiva scrittura avvenga alla fine del file, infatti se questo è stato
aperto anche da un altro processo che vi ha scritto, la fine del file può
essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
- condition}, vedi sez.~\ref{sec:file_atomic}).
+ condition}, vedi sez.~\ref{sec:file_shared_access}).
Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
con \func{lseek} è possibile impostare una posizione anche oltre la corrente
fine del file. In tal caso alla successiva scrittura il file sarà esteso a
-partire da detta posizione, ed in questo si ha quella che viene chiamata la
-creazione di un \index{file!\textit{hole}} \textsl{buco} nel file. Il nome
-deriva dal fatto che nonostante la dimensione del file sia cresciuta in
-seguito alla scrittura effettuata, lo spazio vuoto fra la precedente fine del
-file ed la nuova parte scritta dopo lo spostamento non corrisponde ad una
-allocazione effettiva di spazio su disco, che sarebbe inutile dato che quella
-zona è effettivamente vuota.
+partire da detta posizione, con la creazione di quello che viene chiamato
+\index{file!\textit{hole}} ``\textsl{buco}'' (in gergo \textit{hole}) nel
+file. Il nome deriva dal fatto che nonostante la dimensione del file sia
+cresciuta in seguito alla scrittura effettuata, lo spazio vuoto fra la
+precedente fine del file ed la nuova parte scritta dopo lo spostamento non
+corrisponde ad una allocazione effettiva di spazio su disco, che sarebbe
+inutile dato che quella zona è effettivamente vuota.
Questa è una delle caratteristiche specifiche della gestione dei file di un
-sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
-chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
-file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
-struttura di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail},
-quello che accade è che nell'\textit{inode} del file viene segnata
-l'allocazione di un blocco di dati a partire dalla nuova posizione, ma non
-viene allocato nulla per le posizioni intermedie; in caso di lettura
-sequenziale del contenuto del file il kernel si accorgerà della presenza del
-buco, e restituirà degli zeri come contenuto di quella parte del file.
+sistema unix-like e si dice che il file in questione è uno \textit{sparse
+ file}. In sostanza, se si ricorda la struttura di un filesystem illustrata
+in fig.~\ref{fig:file_filesys_detail}, quello che accade è che \itindex{inode}
+nell'\textit{inode} del file viene segnata l'allocazione di un blocco di dati
+a partire dalla nuova posizione, ma non viene allocato nulla per le posizioni
+intermedie; in caso di lettura sequenziale del contenuto del file il kernel si
+accorgerà della presenza del buco, e restituirà degli zeri come contenuto di
+quella parte del file.
Questa funzionalità comporta una delle caratteristiche della gestione dei file
su Unix che spesso genera più confusione in chi non la conosce, per cui
Questo avviene proprio perché in un sistema unix-like la dimensione di un file
è una caratteristica del tutto indipendente dalla quantità di spazio disco
-effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
-proprietà del file. La dimensione viene aggiornata automaticamente quando si
-estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
-struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
-\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
+effettivamente allocato, e viene registrata \itindex{inode}
+sull'\textit{inode} come le altre proprietà del file. La dimensione viene
+aggiornata automaticamente quando si estende un file scrivendoci, e viene
+riportata dal campo \var{st\_size} di una struttura \struct{stat} quando si
+effettua la chiamata ad una delle funzioni \texttt{*stat} viste in
+sez.~\ref{sec:file_stat}.
Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
la dimensione di un file sarà più o meno corrispondente alla quantità di
spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
sposta in una posizione oltre la fine corrente del file, o come quello
accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
-di un file con una \func{truncate}, in cui in sostanza di modifica il valore
+di un file con una \func{truncate}, in cui in sostanza si modifica il valore
della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
consente di creare inizialmente file di dimensioni anche molto grandi, senza
dover occupare da subito dello spazio disco che in realtà sarebbe
\itindend{sparse~file}
-
-\subsection{Le funzioni per la lettura}
+A partire dal kernel 3.1, riprendendo una interfaccia adottata su Solaris,
+sono state aggiunti due nuovi valori per l'argomento \param{whence}, riportati
+nella seconda sezione di tab.~\ref{tab:lseek_whence_values}, che consentono di
+riconoscere la presenza di \index{file!\textit{hole}} \textit{hole}
+all'interno dei file ad uso di quelle applicazioni (come i programmi di
+backup) che possono salvare spazio disco nella copia degli \textit{sparse
+ file}. Una applicazione può così determinare la presenza di un
+\index{file!\textit{hole}} \textit{hole} usando \const{SEEK\_HOLE} all'inizio
+del file e determinare poi l'inizio della successiva sezione di dati usando
+\const{SEEK\_DATA}. Per compatibilità con i filesystem che non supportano
+questa funzionalità è previsto comunque che in tal caso \const{SEEK\_HOLE}
+riporti sempre la fine del file e \const{SEEK\_DATA} il valore
+di \param{offset}.
+
+Inoltre la decisione di come riportare (o di non riportare) la presenza di un
+\index{file!\textit{hole}} buco in un file è lasciata all'implementazione del
+filesystem, dato che esistono vari motivi per cui una sezione di un file può
+non contenere dati ed essere riportata come tale (ad esempio può essere stata
+preallocata con \func{fallocate}, vedi sez.~\ref{sec:file_fadvise}) oltre a
+quelle classiche appena esposte. Questo significa che l'uso di questi nuovi
+valori non garantisce la mappatura della effettiva allocazione dello spazio
+disco di un file, per il quale esiste una specifica operazione di controllo
+(vedi sez.~\ref{sec:file_ioctl}).
+
+
+
+\subsection{Le funzioni per la lettura di un file}
\label{sec:file_read}
Una volta che un file è stato aperto (con il permesso in lettura) si possono
-leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
-prototipo è:
+leggere i dati che contiene utilizzando la funzione di sistema \funcd{read},
+il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
+ \item[\errcode{EAGAIN}] la funzione non ha nessun dato da restituire e si è
+ aperto il file con \const{O\_NONBLOCK}.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] \param{fd} è associato ad un oggetto non leggibile,
+ o lo si è ottenuto da \func{timerfd\_create} (vedi
+ sez.~\ref{sec:sig_signalfd_eventfd}) e si è usato un valore sbagliato
+ per \param{size} o si è usato \const{O\_DIRECT} ed il buffer non è
+ allineato.
+ \item[\errval{EIO}] si è tentata la lettura dal terminale di controllo
+ essendo in background (vedi sez.~\ref{sec:term_io_design}).
\end{errlist}
- ed inoltre
- nel loro significato generico.}
+ ed inoltre \errval{EBADF}, \errval{EFAULT} e \errval{EISDIR}, nel loro
+ significato generico.}
\end{funcproto}
-\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
-
- Cerca di leggere \param{count} byte dal file \param{fd} al buffer
- \param{buf}.
-
- \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
- aver potuto leggere qualsiasi dato.
- \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
- era aperto il file in modalità \const{O\_NONBLOCK}.
- \end{errlist}
- ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
- \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
- natura dell'oggetto connesso a \param{fd}.}
-\end{prototype}
-
-La funzione tenta di leggere \param{count} byte a partire dalla posizione
-corrente nel file. Dopo la lettura la posizione sul file è spostata
-automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
-funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
-presente che non è detto che la funzione \func{read} restituisca sempre il
+La funzione tenta di leggere \param{count} byte dal file \param{fd} a partire
+dalla posizione corrente, scrivendoli nel buffer \param{buf}. Dopo la lettura
+la posizione sul file è spostata automaticamente in avanti del numero di byte
+letti. Se \param{count} è zero la funzione restituisce zero senza nessun altro
+risultato. Inoltre che non è detto che la funzione \func{read} restituisca il
numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
-può restituire un numero di byte inferiore; questo è un comportamento normale,
-e non un errore, che bisogna sempre tenere presente.
+può restituire un numero di byte inferiore: questo è un comportamento normale,
+e non un errore, che bisogna sempre tenere presente.
La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
di quanto il file ne contenga. In questo caso il file viene letto fino alla
come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
-dati ricevuti fino al momento della lettura.
+dati ricevuti fino al momento della lettura, o i terminali, per i quali si
+applicano inoltre ulteriori condizioni che approfondiremo in
+sez.~\ref{sec:sess_terminal_io}.
Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
\errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
quando la \func{read} è bloccata in attesa di dati in ingresso e viene
-interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
-rieseguire la funzione. Torneremo in dettaglio sull'argomento in
+interrotta da un segnale. In tal caso l'azione da intraprendere è quella di
+rieseguire la funzione, torneremo in dettaglio sull'argomento in
sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
-in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
-dati in ingresso: la funzione allora ritorna immediatamente con un errore
+in modalità non bloccante (con \const{O\_NONBLOCK}) e non ci sono dati in
+ingresso: la funzione allora ritorna immediatamente con un errore
\errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
- \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
- \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
-disponibili occorre provare a ripetere la lettura in un secondo tempo.
+ \errcode{EWOULDBLOCK}, in Linux, con la \acr{glibc}, questa è sinonima di
+ \errcode{EAGAIN}, ma se si vuole essere completamente portabili occorre
+ verificare entrambi i valori, dato che POSIX.1-2001 non richiede che siano
+ coincidenti.} che indica soltanto che non essendoci al momento dati
+disponibili occorre provare a ripetere la lettura in un secondo tempo,
+torneremo sull'argomento in sez.~\ref{sec:file_noblocking}.
La funzione \func{read} è una delle \textit{system call} fondamentali,
esistenti fin dagli albori di Unix, ma nella seconda versione delle
precedenti sia del kernel che delle librerie la funzione non è disponibile.}
(quello che viene chiamato normalmente Unix98, vedi
sez.~\ref{sec:intro_xopen}) è stata introdotta la definizione di un'altra
-funzione di lettura, \funcd{pread}, il cui prototipo è:
-\begin{prototype}{unistd.h}
-{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
-
-Cerca di leggere \param{count} byte dal file \param{fd}, a partire dalla
-posizione \param{offset}, nel buffer \param{buf}.
-
-\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
- visti per \func{read} e \func{lseek}.}
-\end{prototype}
+funzione di sistema, \funcd{pread}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
+\fdesc{Legge a partire da una posizione sul file.}
+}
+
+{La funzione ritorna il numero di byte letti in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori già visti per
+ \func{read} e \func{lseek}.}
+\end{funcproto}
La funzione prende esattamente gli stessi argomenti di \func{read} con lo
stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
da una \func{lseek} che riporti al valore precedente la posizione corrente sul
file, ma permette di eseguire l'operazione atomicamente. Questo può essere
importante quando la posizione sul file viene condivisa da processi diversi
-(vedi sez.~\ref{sec:file_sharing}). Il valore di
+(vedi sez.~\ref{sec:file_shared_access}). Il valore di
\param{offset} fa sempre riferimento all'inizio del file.
La funzione \func{pread} è disponibile anche in Linux, però diventa
accessibile solo attivando il supporto delle estensioni previste dalle
\textit{Single Unix Specification} con la definizione della macro:
-\begin{verbatim}
+\begin{Example}
#define _XOPEN_SOURCE 500
-\end{verbatim}
+\end{Example}
e si ricordi di definire questa macro prima dell'inclusione del file di
dichiarazioni \headfile{unistd.h}.
-\subsection{Le funzioni per la scrittura}
+\subsection{Le funzioni per la scrittura di un file}
\label{sec:file_write}
Una volta che un file è stato aperto (con il permesso in scrittura) si può
-scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
-\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
-
- Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
-
- \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
- valori:
+scrivere su di esso utilizzando la funzione di sistema \funcd{write}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{ssize\_t write(int fd, void * buf, size\_t count)}
+\fdesc{Scrive i dati su un file.}
+}
+
+{La funzione ritorna il numero di byte scritti in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
- la scrittura.
+ \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
+ modalità \const{O\_NONBLOCK}.
\item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
consentita dal filesystem o il limite per le dimensioni dei file del
processo o su una posizione oltre il massimo consentito.
+ \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
+ potuto scrivere qualsiasi dato.
+ \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
+ la scrittura o si è usato \const{O\_DIRECT} ed il buffer non è allineato.
\item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
chiuso in lettura; in questo caso viene anche generato il segnale
\signal{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
funzione ritorna questo errore.
- \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
- potuto scrivere qualsiasi dato.
- \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
- modalità \const{O\_NONBLOCK}.
\end{errlist}
- ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
- \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
- dipendenti dalla natura dell'oggetto connesso a \param{fd}.}
-\end{prototype}
+ ed inoltre \errval{EBADF}, \errval{EFAULT}, \errval{EIO}, \errval{EISDIR},
+ \errval{ENOSPC} nel loro significato generico.}
+\end{funcproto}
+
Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
a partire dalla posizione corrente nel file e sposta automaticamente la
Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
per scrivere alla posizione indicata senza modificare la posizione corrente
nel file, il suo prototipo è:
-\begin{prototype}{unistd.h}
-{ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
-
-Cerca di scrivere sul file \param{fd}, a partire dalla posizione
-\param{offset}, \param{count} byte dal buffer \param{buf}.
-
-\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
- visti per \func{write} e \func{lseek}.}
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
+\fdesc{Scrive a partire da una posizione sul file.}
+}
+
+{La funzione ritorna il numero di byte letti in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori già visti per
+ \func{write} e \func{lseek}.}
+\end{funcproto}
+
\noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
-\subsection{La condivisione dei files}
-\label{sec:file_sharing}
+\subsection{La gestione dell'accesso concorrente ai files}
+\label{sec:file_shared_access}
In sez.~\ref{sec:file_fd} abbiamo descritto brevemente l'architettura
dell'interfaccia con i file da parte di un processo, mostrando in
fig.~\ref{fig:file_proc_file} le principali strutture usate dal kernel;
esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
-confronti dell'accesso allo stesso file da parte di processi diversi.
+confronti dell'accesso concorrente allo stesso file da parte di processi
+diversi.
\begin{figure}[!htb]
\centering
- \includegraphics[width=15cm]{img/filemultacc}
+ \includegraphics[width=12cm]{img/filemultacc}
\caption{Schema dell'accesso allo stesso file da parte di due processi
diversi}
\label{fig:file_mult_acc}
processo avrà una sua voce nella \textit{file table} referenziata da un
diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
nella \itindex{file~table} \textit{file table} faranno però riferimento allo
-stesso \itindex{inode} inode su disco.
+stesso \itindex{inode} \textit{inode} su disco.
Questo significa che ciascun processo avrà la sua posizione corrente sul file,
la sua modalità di accesso e versioni proprie di tutte le proprietà che
azione simultanea sullo stesso file, in particolare occorre tenere presente
che:
\begin{itemize}
-\item ciascun processo può scrivere indipendentemente; dopo ciascuna
- \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
- scrittura eccede la dimensione corrente del file questo verrà esteso
- automaticamente con l'aggiornamento del campo \var{i\_size} \itindex{inode}
- nell'inode.
+\item ciascun processo può scrivere indipendentemente, dopo ciascuna
+ \func{write} la posizione corrente sarà cambiata solo nel processo
+ scrivente. Se la scrittura eccede la dimensione corrente del file questo
+ verrà esteso automaticamente con l'aggiornamento del campo \var{i\_size}
+ della struttura \kstruct{inode}.
\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
le volte che viene effettuata una scrittura la posizione corrente viene
- prima impostata alla dimensione corrente del file letta \itindex{inode}
- dall'inode. Dopo la scrittura il file viene automaticamente esteso.
+ prima impostata alla dimensione corrente del file letta dalla struttura
+ \kstruct{inode}. Dopo la scrittura il file viene automaticamente esteso.
\item l'effetto di \func{lseek} è solo quello di cambiare il campo
\var{f\_pos} nella struttura \kstruct{file} della \itindex{file~table}
\textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
si usa per porsi alla fine del file la posizione viene impostata leggendo la
- dimensione corrente \itindex{inode} dall'inode.
+ dimensione corrente dalla struttura \kstruct{inode}.
\end{itemize}
\begin{figure}[!htb]
\centering
- \includegraphics[width=15cm]{img/fileshar}
+ \includegraphics[width=12cm]{img/fileshar}
\caption{Schema dell'accesso ai file da parte di un processo figlio}
\label{fig:file_acc_child}
\end{figure}
Il secondo caso è quello in cui due file descriptor di due processi diversi
-puntino alla stessa voce nella \itindex{file~table} \textit{file table};
-questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
+puntino alla stessa voce nella \itindex{file~table} \textit{file table}.
+Questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
sez.~\ref{sec:proc_fork}). La situazione è illustrata in
fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
dello spazio di indirizzi del padre, riceverà anche una copia di
-\kstruct{file\_struct} e relativa tabella dei file aperti.
-
-In questo modo padre e figlio avranno gli stessi file descriptor che faranno
-riferimento alla stessa voce nella \textit{file table}, condividendo così la
-posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
-sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
-corrente nel file varierà per entrambi i processi (in quanto verrà modificato
-\var{f\_pos} che è lo stesso per entrambi).
-
-Si noti inoltre che anche i \itindex{file~status~flag} flag di stato del file
-(quelli impostati dall'argomento \param{flag} di \func{open}) essendo tenuti
-nella voce della \textit{file table}\footnote{per la precisione nel campo
- \var{f\_flags} di \kstruct{file}, vedi fig.~\ref{fig:kstruct_file}.},
-vengono in questo caso condivisi. Ai file però sono associati anche altri
-flag, dei quali l'unico usato al momento è \const{FD\_CLOEXEC}, detti
-\index{file~descriptor~flags} \textit{file descriptor flags}. Questi ultimi
-sono tenuti invece in \kstruct{file\_struct}, e perciò sono specifici di
-ciascun processo e non vengono modificati dalle azioni degli altri anche in
-caso di condivisione della stessa voce della \textit{file table}.
-
-
-
-\subsection{Operazioni atomiche con i file}
-\label{sec:file_atomic}
-
-Come si è visto in un sistema unix-like è sempre possibile per più processi
-accedere in contemporanea allo stesso file, e che le operazioni di lettura e
-scrittura possono essere fatte da ogni processo in maniera autonoma in base
-ad una posizione corrente nel file che è locale a ciascuno di essi.
-
-Se dal punto di vista della lettura dei dati questo non comporta nessun
-problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
-maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
-di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
-utilizzare meccanismi di sincronizzazione più complessi (come il
-\itindex{file~locking} \textit{file locking}, che esamineremo in
-sez.~\ref{sec:file_locking}).
+\kstruct{file\_struct} e della relativa tabella dei file aperti.
+
+Questo significa che il figlio avrà gli stessi file aperti del padre, in
+quanto la sua \kstruct{file\_struct}, pur essendo allocata in maniera
+indipendente, contiene gli stessi valori di quella del padre e quindi i suoi
+file descriptor faranno riferimento alla stessa voce nella
+\itindex{file~table} \textit{file table}, condividendo così la posizione
+corrente sul file. Questo ha le conseguenze descritte a suo tempo in
+sez.~\ref{sec:proc_fork}: in caso di scrittura o lettura da parte di uno dei
+due processi, la posizione corrente nel file varierà per entrambi, in quanto
+verrà modificato il campo \var{f\_pos} della struttura \kstruct{file}, che è
+la stessa per entrambi. Questo consente una sorta di
+``\textsl{sincronizzazione}'' automatica della posizione sul file fra padre e
+figlio che occorre tenere presente.
+
+Si noti inoltre che in questo caso anche i \itindex{file~status~flag} flag di
+stato del file, essendo mantenuti nella struttura \kstruct{file} della
+\textit{file table}, vengono condivisi, per cui una modifica degli stessi con
+\func{fcntl} (vedi sez.~\ref{sec:file_fcntl}) si applicherebbe a tutti
+processi che condividono la voce nella \itindex{file~table} \textit{file
+ table}. Ai file però sono associati anche altri flag, dei quali l'unico
+usato al momento è \const{FD\_CLOEXEC}, detti \itindex{file~descriptor~flags}
+\textit{file descriptor flags}; questi invece sono mantenuti in
+\kstruct{file\_struct}, e perciò sono locali per ciascun processo e non
+vengono modificati dalle azioni degli altri anche in caso di condivisione
+della stessa voce della \itindex{file~table} \textit{file table}.
+
+Si tenga presente dunque che in un sistema unix-like è sempre possibile per
+più processi accedere in contemporanea allo stesso file e che non esistono, a
+differenza di altri sistemi operativi, dei meccanismi di blocco o di
+restrizione dell'accesso impliciti se più processi vogliono accedere allo
+stesso file. Questo significa che le operazioni di lettura e scrittura vengono
+sempre fatte da ogni processo in maniera autonoma, utilizzando una posizione
+corrente nel file che normalmente (a meno di non trovarsi nella situazione di
+fig.~\ref{fig:file_acc_child}) è locale a ciascuno di essi.
+
+Dal punto di vista della lettura dei dati questo comporta la possibilità di
+poter leggere dati non coerenti in caso di scrittura contemporanea da parte di
+un altro processo. Dal punto di vista della scrittura invece si potranno avere
+sovrapposizioni imprevedibili quando due processi scrivono nella stessa
+sezione di file, dato che ciascuno lo farà in maniera indipendente. Il
+sistema però fornisce in alcuni casi la possibilità di eseguire alcune
+operazioni di scrittura in maniera coordinata anche senza utilizzare dei
+meccanismi di sincronizzazione espliciti come il \itindex{file~locking}
+\textit{file locking}, che esamineremo in sez.~\ref{sec:file_locking}.
Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
vari processi devono scrivere alla fine di un file (ad esempio un file di
log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
fine del file e poi scrivere può condurre ad una \itindex{race~condition}
-\textit{race condition}: infatti può succedere che un secondo processo scriva
-alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
-abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
-ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
-più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
-secondo processo.
-
-Il problema è che usare due \textit{system call} in successione non è
-un'operazione atomica; il problema è stato risolto introducendo la modalità
-\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
-descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
-alla fine del file prima di effettuare la scrittura, e poi estende il file.
-Tutto questo avviene all'interno di una singola \textit{system call} (la
-\func{write}) che non essendo interrompibile da un altro processo costituisce
-un'operazione atomica.
-
-Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
-creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
-esiste. In questo caso la sequenza logica porterebbe a verificare prima
-l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
-di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
- condition} da parte di un altro processo che crea lo stesso file fra il
-controllo e la creazione.
-
-Per questo motivo sono stati introdotti per \func{open} i due flag
-\const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
-dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
-creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
-di una singola \textit{system call} (per i dettagli sull'uso di questa
-caratteristica si veda sez.~\ref{sec:ipc_file_lock}).
-
-
-\subsection{Le funzioni \func{sync} e \func{fsync}}
-\label{sec:file_sync}
-
-% TODO, aggiungere syncfs, introdotta con il 2.6.39
-
-Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
-sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
-asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
-secondo tempo rispetto al momento della esecuzione della \func{write}.
-
-Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
-sistema mette a disposizione delle funzioni che provvedono a forzare lo
-scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
- questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
- l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
- ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
- scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
-prototipo è:
-\begin{prototype}{unistd.h}{int sync(void)}
-
- Sincronizza il buffer della cache dei file col disco.
-
- \bodydesc{La funzione ritorna sempre zero.}
-\end{prototype}
-\noindent i vari standard prevedono che la funzione si limiti a far partire
-le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
-la funzione aspetta la conclusione delle operazioni di sincronizzazione del
-kernel.
-
-La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
-esplicitamente lo scarico dei dati su disco, o dal demone di sistema
-\cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
-valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
-in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
- partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
-tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
-può essere controllato attraverso il file \sysctlfile{vm/bdflush} (per
-il significato dei valori si può leggere la documentazione allegata al kernel
-in \file{Documentation/sysctl/vm.txt}).
-
-Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
-sicuri che i dati di un database sono stati registrati su disco) si possono
-usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
-\begin{functions}
- \headdecl{unistd.h}
- \funcdecl{int fsync(int fd)}
- Sincronizza dati e meta-dati del file \param{fd}
- \funcdecl{int fdatasync(int fd)}
- Sincronizza i dati del file \param{fd}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assume i valori:
- \begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
- che non supporta la sincronizzazione.
- \end{errlist}
- ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
-\end{functions}
-
-Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
-file specificato, ed attendono fino alla conclusione delle operazioni;
-\func{fsync} forza anche la sincronizzazione dei meta-dati del file (che
-riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
-altri dati contenuti \itindex{inode} nell'inode che si leggono con \func{fstat},
-come i tempi del file).
-
-Si tenga presente che questo non comporta la sincronizzazione della
-directory che contiene il file (e scrittura della relativa voce su
-disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
- il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
- il kernel provvede anche alla sincronizzazione automatica delle voci
- delle directory.}
-
-
-\subsection{Le funzioni \func{dup} e \func{dup2}}
+\textit{race condition}l infatti può succedere che un secondo processo scriva
+alla fine del file fra la \func{lseek} e la \func{write}. In questo caso, come
+abbiamo appena visto, il file sarà esteso, ma il primo processo, che avrà la
+posizione corrente che aveva impostato con la \func{lseek} che non corrisponde
+più alla fine del file, e la sua successiva \func{write} sovrascriverà i dati
+del secondo processo.
+
+Il problema deriva dal fatto che usare due \textit{system call} in successione
+non è mai un'operazione atomica dato che il kernel può interrompere
+l'esecuzione del processo fra le due. Nel caso specifico il problema è stato
+risolto introducendo la modalità di scrittura \itindex{append~mode} in
+\textit{append}, attivabile con il flag \const{O\_APPEND}. In questo caso
+infatti, come abbiamo illustrato in sez.~\ref{sec:file_open_close}, è il
+kernel che aggiorna automaticamente la posizione alla fine del file prima di
+effettuare la scrittura, e poi estende il file. Tutto questo avviene
+all'interno di una singola \textit{system call}, la \func{write}, che non
+essendo interrompibile da un altro processo realizza un'operazione atomica.
+
+
+\subsection{La duplicazione dei file descriptor}
\label{sec:file_dup}
-Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
+Abbiamo già visto in sez.~\ref{sec:file_shared_access} come un processo figlio
condivida gli stessi file descriptor del padre; è possibile però ottenere un
comportamento analogo all'interno di uno stesso processo \textit{duplicando}
-un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
-prototipo è:
-\begin{prototype}{unistd.h}{int dup(int oldfd)}
- Crea una copia del file descriptor \param{oldfd}.
-
- \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
- valori:
+un file descriptor. Per far questo si usa la funzione di sistema \funcd{dup},
+il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int dup(int oldfd)}
+\fdesc{Crea un file descriptor duplicato.}
+}
+
+{La funzione ritorna il nuovo file descriptor in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
\item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
descriptor aperti.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
file descriptor è una copia esatta del precedente ed entrambi possono essere
interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
-può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
-semplicemente quello di copiare il valore nella struttura
-\kstruct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
-alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
-file descriptor è \textsl{duplicato}, da cui il nome della funzione.
+può fare riferimento a fig.~\ref{fig:file_dup}. L'effetto della funzione è
+semplicemente quello di copiare il valore di un certo file descriptor in
+un altro all'interno della struttura \kstruct{file\_struct}, cosicché anche
+questo faccia riferimento alla stessa voce nella \textit{file table}. Per
+questo motivo si dice che il nuovo file descriptor è ``\textsl{duplicato}'',
+da cui il nome della funzione.
\begin{figure}[!htb]
- \centering \includegraphics[width=14cm]{img/filedup}
+ \centering \includegraphics[width=12cm]{img/filedup}
\caption{Schema dell'accesso ai file duplicati}
\label{fig:file_dup}
\end{figure}
Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
-duplicati condivideranno eventuali lock, \textit{file status flag}, e
-posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
-posizione su uno dei due file descriptor, essa risulterà modificata anche
-sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
-della \textit{file table} a cui entrambi fanno riferimento). L'unica
-differenza fra due file descriptor duplicati è che ciascuno avrà il suo
-\textit{file descriptor flag}; a questo proposito va specificato che nel caso
-di \func{dup} il flag di \textit{close-on-exec} \itindex{close-on-exec} (vedi
-sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
-nella copia.
-
-L'uso principale di questa funzione è per la redirezione dell'input e
-dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
-diventa così possibile associare un file (o una pipe) allo standard input o
-allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
-quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
-il file che si vuole sostituire, cosicché il suo file descriptor possa esser
-restituito alla chiamata di \func{dup}, come primo file descriptor
-disponibile.
-
-Dato che questa è l'operazione più comune, è prevista una diversa versione
-della funzione, \funcd{dup2}, che permette di specificare esplicitamente
-qual è il valore di file descriptor che si vuole avere come duplicato; il suo
-prototipo è:
-\begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
-
- Rende \param{newfd} una copia del file descriptor \param{oldfd}.
-
- \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+duplicati condivideranno eventuali lock (vedi sez.~\ref{sec:file_locking}),
+\itindex{file~status~flag} i flag di stato, e la posizione corrente sul
+file. Se ad esempio si esegue una \func{lseek} per modificare la posizione su
+uno dei due file descriptor, essa risulterà modificata anche sull'altro, dato
+che quello che viene modificato è lo stesso campo nella voce della
+\textit{file table} a cui entrambi fanno riferimento.
+
+L'unica differenza fra due file descriptor duplicati è che ciascuno avrà un
+suo \textit{file descriptor flag} indipendente. A questo proposito deve essere
+tenuto presente che nel caso in cui si usi \func{dup} per duplicare un file
+descriptor, se questo ha il flag di \textit{close-on-exec}
+\itindex{close-on-exec} attivo (vedi sez.~\ref{sec:proc_exec} e
+sez.~\ref{sec:file_fcntl}), questo verrà cancellato nel file descriptor
+restituito come copia.
+
+L'uso principale di questa funzione è nella shell per la redirezione dei file
+standard di tab.~\ref{tab:file_std_files} fra l'esecuzione di una \func{fork}
+e la successiva \func{exec}. Diventa così possibile associare un file (o una
+pipe) allo \itindex{standard~input} \textit{standard input} o allo
+\itindex{standard~output} \textit{standard output} (vedremo un esempio in
+sez.~\ref{sec:ipc_pipe_use}, quando tratteremo le pipe).
+
+Ci si può chiedere perché non sia in questo caso sufficiente chiudere il file
+standard che si vuole redirigere e poi aprire direttamente con \func{open} il
+file vi si vuole far corrispondere, invece di duplicare un file descriptor che
+si è già aperto. La risposta sta nel fatto che il file che si vuole redirigere
+non è detto sia un file regolare, ma potrebbe essere, come accennato, anche
+una fifo o un socket, oppure potrebbe essere un file associato ad un file
+descriptor che si è ereditato già aperto (ad esempio attraverso un'altra
+\func{exec}) da un processo antenato del padre, del quale non si conosce il
+nome. Operando direttamente con i file descriptor \func{dup} consente di
+ignorare le origini del file descriptor che si duplica e funziona in maniera
+generica indipendentemente dall'oggetto a cui questo fa riferimento.
+
+Per ottenere la redirezione occorre pertanto disporre del file descriptor
+associato al file che si vuole usare e chiudere il file descriptor che si
+vuole sostituire, cosicché esso possa esser restituito alla successiva
+chiamata di \func{dup} come primo file descriptor disponibile. Dato che
+questa è l'operazione più comune, è prevista un'altra funzione di sistema,
+\funcd{dup2}, che permette di specificare esplicitamente qual è il numero di
+file descriptor che si vuole ottenere come duplicato; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int dup2(int oldfd, int newfd)}
+\fdesc{Duplica un file descriptor su un altro.}
+}
+
+{La funzione ritorna il nuovo file descriptor in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
un valore fuori dall'intervallo consentito per i file descriptor.
+ \item[\errcode{EBUSY}] si è rilevata la possibilità di una
+ \itindex{race~condition} \textit{race condition}.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
descriptor aperti.
- \end{errlist}}
-\end{prototype}
-\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
-avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
-sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
-allo stesso valore per il file descriptor).
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione duplica il file descriptor \param{oldfd} su un altro file
+descriptor di valore \param{newfd}. Qualora il file descriptor \param{newfd}
+sia già aperto, come avviene ad esempio nel caso della duplicazione di uno dei
+file standard di tab.~\ref{tab:file_std_files}, esso sarà prima chiuso e poi
+duplicato. Se \param{newfd} è uguale a \param{oldfd} la funzione non fa nulla
+e si limita a restituire \param{newfd}.
+
+L'uso di \func{dup2} ha vari vantaggi rispetto alla combinazione di
+\func{close} e \func{dup}; anzitutto se \param{oldfd} è uguale \param{newfd}
+questo verrebbe chiuso e \func{dup} fallirebbe, ma soprattutto l'operazione è
+atomica e consente di evitare una \itindex{race~condition} \textit{race
+ condition} in cui dopo la chiusura del file si potrebbe avere la ricezione
+di un segnale il cui gestore (vedi sez.~\ref{sec:sig_signal_handler}) potrebbe
+a sua volta aprire un file, per cui alla fine \func{dup} restituirebbe un file
+descriptor diverso da quello voluto.
+
+Con Linux inoltre la funzione prevede la possibilità di restituire l'errore
+\errcode{EBUSY}, che non è previsto dallo standard, quando viene rilevata la
+possibilità di una \itindex{race~condition} \textit{race condition} interna in
+cui si cerca di duplicare un file descriptor che è stato allocato ma per il
+quale non sono state completate le operazioni di apertura.\footnote{la
+ condizione è abbastanza peculiare e non attinente al tipo di utilizzo
+ indicato, quanto piuttosto ad un eventuale tentativo di duplicare file
+ descriptor non ancora aperti, la condizione di errore non è prevista dallo
+ standard, ma in condizioni simili FreeBSD risponde con un errore di
+ \errval{EBADF}, mentre OpenBSD elimina la possibilità di una \textit{race
+ condition} al costo di una perdita di prestazioni.} In tal caso occorre
+ritentare l'operazione.
La duplicazione dei file descriptor può essere effettuata anche usando la
funzione di controllo dei file \func{fcntl} (che esamineremo in
sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
-\param{newfd} diventa equivalente a \func{dup}.
+\param{newfd} diventa equivalente a \func{dup}. La sola differenza fra le due
+funzioni (a parte la sintassi ed i diversi codici di errore) è che \func{dup2}
+chiude il file descriptor \param{newfd} se questo è già aperto, garantendo che
+la duplicazione sia effettuata esattamente su di esso, invece \func{fcntl}
+restituisce il primo file descriptor libero di valore uguale o maggiore
+di \param{newfd}, per cui se \param{newfd} è aperto la duplicazione avverrà su
+un altro file descriptor.
+
+Su Linux inoltre è presente una terza funzione di sistema non
+standard,\footnote{la funzione è stata introdotta con il kernel 2.6.27 e resa
+ disponibile con la \acr{glibc} 2.9.} \funcd{dup3}, che consente di duplicare
+un file descriptor reimpostandone i flag, per usarla occorre definire la macro
+\macro{\_GNU\_SOURCE} ed il suo prototipo è:
-La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
- diversi codici di errore.} è che \func{dup2} chiude il file descriptor
-\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
-effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
-file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
-\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int dup3(int oldfd, int newfd, int flags)}
+\fdesc{Duplica un file descriptor su un altro.}
+}
+
+{La funzione ritorna il nuovo file descriptor in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{dup2} più \errcode{EINVAL} qualora \param{flags} contenga un valore
+ non valido o \param{newfd} sia uguale a \param{oldfd}.
+}
+\end{funcproto}
+La funzione è identica a \func{dup2} ma prevede la possibilità di mantenere il
+flag di \textit{close-on-exec} \itindex{close-on-exec} sul nuovo
+file descriptor specificando \const{O\_CLOEXEC} in \param{flags} (che è l'unico
+flag usabile in questo caso). Inoltre rileva esplicitamente la possibile
+coincidenza fra \param{newfd} e \param{oldfd}, fallendo con un errore di
+\errval{EINVAL}.
+
+
+\subsection{Le funzioni di sincronizzazione dei dati}
+\label{sec:file_sync}
+
+Come accennato in sez.~\ref{sec:file_open_close} tutte le operazioni di
+scrittura sono in genere bufferizzate dal kernel, che provvede ad effettuarle
+in maniera asincrona, ad esempio accorpando gli accessi alla stessa zona del
+disco, in un secondo tempo rispetto al momento della esecuzione della
+\func{write}.
+
+Per questo motivo quando è necessaria una sincronizzazione dei dati il sistema
+mette a disposizione delle funzioni che provvedono a forzare lo scarico dei
+dati dai buffer del kernel. La prima di queste funzioni di sistema è
+\funcd{sync}, il cui prototipo è:\footnote{questo è il prototipo usato a
+ partire dalla \acr{glibc} 2.2.2 seguendo gli standard, in precedenza la
+ funzione era definita come \code{int sync(void)} e ritornava sempre $0$.}
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{void sync(void)}
+\fdesc{Sincronizza il buffer della cache dei file col disco.}
+}
+
+{La funzione non ritorna nulla e non prevede condizioni di errore.}
+\end{funcproto}
+
+I vari standard prevedono che la funzione si limiti a far partire le
+operazioni, ritornando immediatamente, con Linux fin dal kernel 1.3.20 invece
+la funzione aspetta la conclusione delle operazioni di sincronizzazione. Si
+tenga presente comunque che questo non dà la garanzia assoluta che i dati
+siano integri dopo la chiamata, l'hardware dei dischi è in genere dotato di un
+suo meccanismo interno di bufferizzazione che può ritardare ulteriormente la
+scrittura effettiva.
+
+La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
+esplicitamente lo scarico dei dati su disco, un tempo era invocata da un
+apposito demone di sistema (in genere chiamato \cmd{update}) che eseguiva lo
+scarico dei dati ad intervalli di tempo fissi. Con le nuove versioni del
+kernel queste operazioni vengono gestite direttamente dal sistema della
+memoria virtuale, attraverso opportuni \textit{task} interni al kernel il cui
+comportamento può essere controllato attraverso il file
+\sysctlfile{vm/bdflush}.\footnote{per il significato dei valori che si possono
+ scrivere in questo file si consulti la documentazione allegata ai sorgenti
+ del kernel nel file \file{Documentation/sysctl/vm.txt}, trattandosi di
+ argomenti di natura sistemistica non li prenderemo in esame.} Si tenga
+presente che la funzione di sistema \funcm{bdflush} che un tempo veniva usata
+per queste impostazioni è deprecata e causa semplicemente la stampa di un
+messaggio nei log del kernel, pertanto non la prenderemo in esame.
+
+Quando si vogliono scaricare soltanto i dati di un singolo file (ad esempio
+essere sicuri che i dati di un database sono stati registrati su disco) si
+possono usare le due funzioni di sistema \funcd{fsync} e \funcd{fdatasync}, i
+cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int fsync(int fd)}
+\fdesc{Sincronizza dati e metadati di un file.}
+\fdecl{int fdatasync(int fd)}
+\fdesc{Sincronizza i dati di un file.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
+ che non supporta la sincronizzazione.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO} nel loro
+ significato generico.}
+\end{funcproto}
+
+Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
+file specificato, ed attendono fino alla conclusione delle operazioni. La
+prima, \func{fsync} forza anche la sincronizzazione dei meta-dati del file,
+che riguardano sia le modifiche alle tabelle di allocazione dei settori, che
+gli altri dati contenuti \itindex{inode} nell'\textit{inode} che si leggono
+con \func{fstat}, come i tempi del file. Se lo scopo dell'operazione, come
+avviene spesso per i database, è assicurarsi che i dati raggiungano il disco e
+siano rileggibili immediatamente in maniera corretta, è sufficiente l'uso di
+\func{fdatasync} che non comporta anche l'esecuzione di operazioni non
+necessarie all'integrità dei dati, come l'aggiornamento dei temi di ultima
+modifica (ed ultimo accesso).
+
+Si tenga presente che l'uso di queste funzioni non comporta la
+sincronizzazione della directory che contiene il file (e scrittura della
+relativa voce su disco) che se necessaria deve essere effettuata
+esplicitamente con \param{sync} sul file descriptor della
+directory.\footnote{in realtà per il filesystem \acr{ext2}, quando lo si monta
+ con l'opzione \cmd{sync}, il kernel provvede anche alla sincronizzazione
+ automatica delle voci delle directory.}
+
+L'uso di \func{sync} presenta in certi casi, quando ci sono più filesystem
+montati, problemi di prestazioni dovute al fatto che la funzione provoca la
+sincronizzazione dei dati su tutti quanti i filesystem, anche quando
+interesserebbe che questo avvenga soltanto su quello dei file su cui si sta
+lavorando.
+
+Per questo motivo è stata introdotta una nuova funzione di sistema,
+\funcd{syncfs},\footnote{introdotta a partire dal kernel 2.6.39, la funzione è
+ specifica di Linux e non prevista da nessuno standard.} che effettua lo
+scarico dei dati soltanto per il filesystem su cui si sta operando, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{void syncfs(int fd)}
+\fdesc{Sincronizza il buffer della cache dei file del singolo filesystem col
+ disco.}
+}
+
+{La funzione non ritorna nulla e non prevede condizioni di errore.}
+\end{funcproto}
\subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
\itindbeg{at-functions}
-Un problema che si pone con l'uso della funzione \func{open}, così come per
-molte altre funzioni che accettano come argomenti dei
-\itindsub{pathname}{relativo} \textit{pathname} relativi, è che, quando un
-\textit{pathname} relativo non fa riferimento alla \index{directory~di~lavoro}
-directory di lavoro corrente, è possibile che alcuni dei suoi componenti
-vengano modificati in parallelo alla chiamata a \func{open}, e questo lascia
-aperta la possibilità di una \itindex{race~condition} \textit{race condition}.
+Un problema generale che si pone con l'uso della funzione \func{open}, così
+come per le altre funzioni che prendono come argomenti dei
+\itindsub{pathname}{relativo} \textit{pathname} relativi, è la possibilità,
+quando un \textit{pathname} relativo non fa riferimento alla
+\index{directory~di~lavoro} directory di lavoro corrente, che alcuni dei suoi
+componenti vengano modificati in parallelo alla chiamata a \func{open}, cosa
+che lascia aperta la possibilità di una \itindex{race~condition} \textit{race
+ condition} in cui c'è spazio per un \itindex{symlink~attack} \textit{symlink
+ attack} (si ricordi quanto visto per \func{access} in
+sez.~\ref{sec:file_perm_management}).
Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
corrente è una proprietà del singolo processo; questo significa che quando si
argomenti successivi restano identici a quelli della corrispondente funzione
ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
come:
-\begin{functions}
- \headdecl{fcntl.h}
- \funcdecl{int openat(int dirfd, const char *pathname, int flags)}
- \funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
- mode))}
-
- Apre un file usando come directory di \index{directory~di~lavoro} lavoro
- corrente \param{dirfd}.
-
- \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{open}, ed in più:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int openat(int dirfd, const char *pathname, int flags)}
+\fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
+ mode))}
+\fdesc{Apre un file a partire da una directory di \index{directory~di~lavoro}
+ lavoro.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{open}, ed in più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
- \textit{pathname} relativo, ma
- \param{dirfd} fa riferimento ad un file.
- \end{errlist}}
-\end{functions}
+ \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
+ \end{errlist}
+}
+\end{funcproto}
Il comportamento delle nuove funzioni è del tutto analogo a quello delle
corrispettive classiche, con la sola eccezione del fatto che se fra i loro
relativo questo sarà risolto rispetto alla directory indicata
da \param{dirfd}; qualora invece si usi un \itindsub{pathname}{assoluto}
\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
-se per
-\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- come le altre costanti \texttt{AT\_*}, è definita in \headfile{fcntl.h},
- pertanto se la si vuole usare occorrerà includere comunque questo file,
- anche per le funzioni che non sono definite in esso.} la risoluzione sarà
-effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
-corrente del processo.
+se per \param{dirfd} si usa il valore speciale
+\const{AT\_FDCWD},\footnote{questa, come le altre costanti \texttt{AT\_*}, è
+ definita in \headfile{fcntl.h}, pertanto se la si vuole usare occorrerà
+ includere comunque questo file, anche per le funzioni che non sono definite
+ in esso.} la risoluzione sarà effettuata rispetto alla directory di
+\index{directory~di~lavoro} lavoro corrente del processo.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
Come esempio di questo secondo tipo di funzioni possiamo considerare
\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
che \func{lchown}; il suo prototipo è:
-\begin{functions}
- \headdecl{unistd.h} \headdecl{fcntl.h}
- \funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
group, int flags)}
+\fdesc{Modifica il proprietario di un file.}
+}
- Modifica la proprietà di un file.
-
- \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{chown}, ed in più:
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{chown}, ed in più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
\item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
\textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
- \end{errlist}}
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
In questo caso il valore di \param{flags} stabilisce il comportamento della
funzione quando la si applica ad un collegamento simbolico, e l'unico valore
solo due funzioni possono usare l'argomento \param{flags} con valori diversi
da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
il suo prototipo è:
-\begin{functions}
- \headdecl{unistd.h}
- \funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
-
- Controlla i permessi di accesso.
-
- \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{access}, ed in più:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
+\fdesc{Controlla i permessi di accesso.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{access}, ed in più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
\item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
\textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
- \end{errlist}}
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La funzione esegue lo stesso controllo di accesso effettuabile con
\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
prototipo è:
-\begin{functions}
- \headdecl{fcntl.h}
- \funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
-
- Rimuove una voce da una directory.
-
- \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{unlink} o di \func{rmdir} a seconda del valore di
- \param{flags}, ed in più:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
+\fdesc{Rimuove una voce da una directory.}
+}
+
+{La funzione ritorna gli stessi valori e gli stessi codici di errore di
+ \func{unlink} o di \func{rmdir} a seconda del valore di \param{flags}, ed in
+ più:
\begin{errlist}
\item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
\item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
\textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
- \end{errlist}}
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
Di default il comportamento di \func{unlinkat} è equivalente a quello che
avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
Per queste operazioni di manipolazione e di controllo delle varie proprietà e
caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
il cui prototipo è:
-\begin{functions}
- \headdecl{unistd.h}
- \headdecl{fcntl.h}
- \funcdecl{int fcntl(int fd, int cmd)}
- \funcdecl{int fcntl(int fd, int cmd, long arg)}
- \funcdecl{int fcntl(int fd, int cmd, struct flock * lock)}
- Esegue una delle possibili operazioni specificate da \param{cmd}
- sul file \param{fd}.
-
- \bodydesc{La funzione ha valori di ritorno diversi a seconda
- dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
- il codice dell'errore è restituito nella variabile \var{errno}; i codici
- possibili dipendono dal tipo di operazione, l'unico valido in generale è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int fcntl(int fd, int cmd)}
+\fdecl{int fcntl(int fd, int cmd, long arg)}
+\fdecl{int fcntl(int fd, int cmd, struct flock * lock)}
+\fdesc{Esegue una operazione di controllo sul file.}
+}
+
+{La funzione ha valori di ritorno diversi a seconda dell'operazione richiesta
+ in caso di successo mentre ritorna sempre $-1$ per un errore, nel qual caso
+ \var{errno} assumerà valori diversi che dipendono dal tipo di operazione,
+ l'unico valido in generale è:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un file aperto.
- \end{errlist}}
-\end{functions}
-
+ \end{errlist}
+}
+\end{funcproto}
Il primo argomento della funzione è sempre il numero di file descriptor
\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
(il comportamento predefinito) restano aperti.
\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
- bit impostati da \func{open} all'apertura del file che vengono memorizzati
- (quelli riportati nella prima e terza sezione di
- tab.~\ref{tab:file_open_flags}).
-% TODO toglire riferimeto a tabella flag e mettere altro
-
+ bit impostati da \func{open} all'apertura del file che vengono memorizzati,
+ quelli riportati in tab.~\ref{tab:open_access_mode_flag} e
+ tab.~\ref{tab:open_operation_flag}).
\item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
specificato da \param{arg}, ritorna un valore nullo in caso di successo o
- $-1$ in caso di errore. Possono essere impostati solo i bit riportati nella
- terza sezione di tab.~\ref{tab:file_open_flags}.\footnote{la pagina di
- manuale riporta come impostabili solo \const{O\_APPEND},
- \const{O\_NONBLOCK} e \const{O\_ASYNC}.}
-% TODO toglire riferimeto a tabella flag e mettere altro
-
+ $-1$ in caso di errore. Possono essere impostati solo i bit riportati in
+ tab.~\ref{tab:open_operation_flag}.\footnote{la pagina di manuale riporta
+ come impostabili solo \const{O\_APPEND}, \const{O\_NONBLOCK} e
+ \const{O\_ASYNC}.}
\item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
\param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
specifiche di ogni dispositivo particolare, usando come riferimento il solito
file descriptor. Il prototipo di questa funzione è:
-\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
-
- Esegue l'operazione di controllo specificata da \param{request} sul file
- descriptor \param{fd}.
-
- \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
- operazioni usano però il valore di ritorno per restituire informazioni. In
- caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
- valori:
+
+\begin{funcproto}{
+\fhead{sys/ioctl.h}
+\fdecl{int ioctl(int fd, int request, ...)}
+\fdesc{Esegue una operazione speciale.}
+}
+
+{La funzione ritorna $0$ in caso di successo nella maggior parte dei casi, ma
+ alcune operazioni possono restituire un valore positivo, mentre ritorna
+ sempre $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
+ valori:
\begin{errlist}
\item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
\item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
validi.
\end{errlist}
- ed inoltre \errval{EBADF} e \errval{EFAULT}.}
-\end{prototype}
-
-La funzione serve in sostanza come meccanismo generico per fare tutte quelle
-operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
-file e che non è possibile effettuare con le funzioni esaminate finora. La
-funzione richiede che si passi come primo argomento un file descriptor
-regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
-il valore dell'argomento \param{request}. Il terzo argomento dipende
-dall'operazione prescelta; tradizionalmente è specificato come \code{char *
- argp}, da intendersi come puntatore ad un area di memoria
+ ed inoltre \errval{EBADF} e \errval{EFAULT} nel loro significato generico.}
+\end{funcproto}
+
+La funzione esegue l'operazione di controllo specificata da \param{request}
+sul file descriptor \param{fd} e serve in sostanza come meccanismo generico
+per fare tutte quelle operazioni che non rientrano nell'interfaccia ordinaria
+della gestione dei file e che non è possibile effettuare con le funzioni
+esaminate finora. La funzione richiede che si passi come primo argomento un
+file descriptor regolarmente aperto, e l'operazione da compiere viene
+selezionata attraverso il valore dell'argomento \param{request}. Il terzo
+argomento dipende dall'operazione prescelta; tradizionalmente è specificato
+come \code{char * argp}, da intendersi come puntatore ad un area di memoria
generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
essere omesso, e per altre è un semplice intero.
(cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
\end{basedescript}
-% TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
+% TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260795/,
+% http://lwn.net/Articles/429345/
+
Si noti però come la gran parte di queste operazioni specifiche dei file (per
essere precisi le prime sei dell'elenco) siano effettuabili in maniera
scrittura (sia per quel che riguarda la bufferizzazione, che le
formattazioni), i \textit{file stream} restano del tutto equivalenti ai file
descriptor (sui quali sono basati), ed in particolare continua a valere quanto
-visto in sez.~\ref{sec:file_sharing} a proposito dell'accesso condiviso ed in
-sez.~\ref{sec:file_access_control} per il controllo di accesso.
+visto in sez.~\ref{sec:file_shared_access} a proposito dell'accesso
+concorrente ed in sez.~\ref{sec:file_access_control} per il controllo di
+accesso.
\itindend{file~stream}
-\subsection{Gli oggetti \type{FILE}}
-\label{sec:file_FILE}
-
-
Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
libreria e contengono tutte le informazioni necessarie a gestire le operazioni
accettano come argomenti solo variabili di questo tipo, che diventa
accessibile includendo l'header file \headfile{stdio.h}.
-
-\subsection{Gli \textit{stream standard}}
-\label{sec:file_std_stream}
-
Ai tre file descriptor standard (vedi tab.~\ref{tab:file_std_files}) aperti
per ogni processo, corrispondono altrettanti \textit{stream}, che
rappresentano i canali standard di input/output prestabiliti; anche questi tre
\funcd{fopen}, \funcd{fdopen} e \funcd{freopen},\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 \textit{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 \textit{stream}
- specificato da \param{stream}, se questo è già aperto prima lo chiude.
-
- \bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
- \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il 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}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{FILE *fopen(const char *path, const char *mode)}
+\fdesc{Apre uno \textit{stream} da un \texttt{pathname}.}
+\fdecl{FILE *fdopen(int fildes, const char *mode)}
+\fdesc{Associa uno \textit{stream} a un file descriptor.}
+\fdecl{FILE *freopen(const char *path, const char *mode, FILE *stream)}
+\fdesc{Chiude uno \textit{stream} e lo riapre su un file diverso.}
+}
+
+{Le funzioni ritornano un puntatore ad un oggetto \type{FILE} in caso di
+ successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà il
+ 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{funcproto}
+
Normalmente la funzione che si usa per aprire uno \textit{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 tab.~\ref{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 sez.~\ref{sec:file_std_stream}): il file \param{path} viene
-associato a \param{stream} e se questo è uno \textit{stream} già aperto viene
+\func{fopen}, essa apre il file specificato dal \textit{pathname} \param{path}
+nella modalità specificata da \param{mode}, che è una stringa che deve
+iniziare con almeno uno dei valori indicati in tab.~\ref{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 sez.~\ref{sec:file_stream}): il file \param{path} viene aperto nella
+modalità indicata da \param{mode} ed associato allo \textit{stream}
+a \param{stream}, e se questo era uno \textit{stream} già aperto viene
preventivamente chiuso.
Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
Uno \textit{stream} viene chiuso con la funzione \funcd{fclose} il cui
prototipo è:
-\begin{prototype}{stdio.h}{int fclose(FILE *stream)}
- Chiude lo \textit{stream} \param{stream}.
-
- \bodydesc{Restituisce 0 in caso di successo e \val{EOF} in caso di errore,
- nel qual caso imposta \var{errno} a \errval{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 lo 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
-\textit{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} (vedi sez.~\ref{sec:file_sync}).
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fclose(FILE *stream)}
+\fdesc{Chiude uno \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e \val{EOF} per un errore, nel
+ qual caso \var{errno} assumerà il valore \errval{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{funcproto}
+
+La funzione chiude lo \textit{stream} \param{stream} ed effettua lo 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 \textit{stream} questo verrà
+rilasciato. La funzione effettua lo scarico solo per i dati presenti nei
+buffer in \textit{user space} usati dalle \acr{glibc}; se si vuole essere
+sicuri che il kernel forzi la scrittura su disco occorrerà effettuare una
+\func{sync} (vedi sez.~\ref{sec:file_sync}).
Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
GNU implementata dalle \acr{glibc}, accessibile avendo definito
\macro{\_GNU\_SOURCE}, il suo prototipo è:
-\begin{prototype}{stdio.h}{int fcloseall(void)}
- Chiude tutti gli \textit{stream}.
-
- \bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
-\end{prototype}
-\noindent 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 sez.~\ref{sec:proc_conclusion}).
-
-
-\subsection{Lettura e scrittura su uno \textit{stream}}
-\label{sec:file_io}
-
-Una delle caratteristiche più utili dell'interfaccia degli \textit{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 sez.~\ref{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 sez.~\ref{sec:file_char_io}.
-\item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
- dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
-\end{enumerate*}
-ed inoltre la modalità di input/output formattato.
-
-A differenza dell'interfaccia dei file descriptor, con gli \textit{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 \ctyp{int}) \val{EOF}\footnote{la costante deve essere
- negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
- valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
-
-Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
-libreria che si appoggiano a delle \textit{system call}, esse non impostano
-direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
-\textit{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 impostato in
-una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del
-funzionamento di \var{errno}).
-
-Per questo motivo tutte le implementazioni delle librerie standard mantengono
-per ogni \textit{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 \funcd{feof} e \funcd{ferror}, i cui prototipi sono:
-\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}.
-
- \bodydesc{Entrambe le funzioni ritornano un valore diverso da zero se
- i relativi flag sono impostati.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fcloseall(void)}
+\fdesc{Chiude tutti gli \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e \val{EOF} per un errore, nel
+ qual caso \var{errno} assumerà gli stessi valori di \func{fclose}.}
+\end{funcproto}
+
+ 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 sez.~\ref{sec:proc_conclusion}).
+
+
+ \subsection{Lettura e scrittura su uno \textit{stream}}
+ \label{sec:file_io}
+
+ Una delle caratteristiche più utili dell'interfaccia degli \textit{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 sez.~\ref{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 sez.~\ref{sec:file_char_io}.
+ \item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
+ dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
+ \end{enumerate*}
+ ed inoltre la modalità di input/output formattato.
+
+ A differenza dell'interfaccia dei file descriptor, con gli \textit{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 \ctyp{int}) \val{EOF}\footnote{la costante deve essere
+ negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
+ valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
+
+ Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
+ libreria che si appoggiano a delle \textit{system call}, esse non impostano
+ direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
+ \textit{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 impostato in
+ una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del
+ funzionamento di \var{errno}).
+
+ Per questo motivo tutte le implementazioni delle librerie standard mantengono
+ per ogni \textit{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 \funcd{feof} e \funcd{ferror}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int feof(FILE *stream)}
+\fdesc{Controlla il flag di \textit{end-of-file} di uno \textit{stream}.}
+\fdecl{int ferror(FILE *stream)}
+\fdesc{Controlla il flag di errore di uno \textit{stream}.}
+}
+
+{Le funzioni ritornano un valore diverso da zero se i relativi flag sono
+ impostati, e non prevedono condizioni di errore.}
+\end{funcproto}
+
\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 \textit{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 \funcd{clearerr}, il cui prototipo è:
-\begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
- Cancella i flag di errore ed \textit{end-of-file} di \param{stream}.
-\end{prototype}
+Entrambi i flag (di errore e di \textit{end-of-file}) possono essere
+cancellati usando la funzione \funcd{clearerr}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{void clearerr(FILE *stream)}
+\fdesc{Cancella i flag di errore ed \textit{end-of-file} di uno
+ \textit{stream}.}
+}
+
+{La funzione non ritorna nulla e prevede condizioni di errore.}
+\end{funcproto}
+
\noindent in genere si usa questa funzione 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. Di 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 \funcd{fread} ed \funcd{fwrite};
i loro prototipi 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)}
-
- Rispettivamente leggono e scrivono \param{nmemb} elementi di dimensione
- \param{size} dal buffer \param{ptr} al file \param{stream}.
-
- \bodydesc{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{funcproto}{
+\fhead{stdio.h}
+\fdecl{size\_t fread(void *ptr, size\_t size, size\_t nmemb, FILE *stream)}
+\fdesc{Legge i dati da uno \textit{stream}.}
+\fdecl{size\_t fwrite(const void *ptr, size\_t size, size\_t nmemb,
+ FILE *stream)}
+\fdesc{Scrive i dati su uno \textit{stream}.}
+}
+
+{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{funcproto}
+
+Le funzioni rispettivamente leggono e scrivono \param{nmemb} elementi di
+dimensione \param{size} dal buffer \param{ptr} al file \param{stream}. 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:
\includecodesnip{listati/WriteVect.c}
in questo caso devono essere specificate le dimensioni di ciascun
elemento ed il numero di quelli che si vogliono scrivere. Un secondo
implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
applicazioni \itindex{thread} \textit{multi-thread} (si veda
sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{size\_t fread\_unlocked(void *ptr, size\_t size, size\_t
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{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,
+\fdecl{size\_t fwrite\_unlocked(const void *ptr, size\_t size,
size\_t nmemb, FILE *stream)}
-
- \bodydesc{Le funzioni sono identiche alle analoghe \func{fread} e
- \func{fwrite} ma non acquisiscono il lock implicito sullo \textit{stream}.}
-\end{functions}
-\noindent entrambe le funzioni sono estensioni GNU previste solo dalle
-\acr{glibc}.
+\fdesc{Leggono o scrivono dati su uno \textit{stream} senza acquisire il lock
+ implicito sullo stesso.}
+}
+
+{Le funzioni ritornano gli stessi valori delle precedenti \func{fread} e
+ \func{fwrite}.}
+\end{funcproto}
+
+% TODO: trattare in generale le varie *_unlocked
\subsection{Input/output a caratteri}
trasferisce un carattere alla volta. Le funzioni per la lettura a
caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{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. È sempre una funzione.
-
- \funcdecl{int getchar(void)} Equivalente a \code{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 è \val{EOF}.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int getc(FILE *stream)}
+\fdecl{int fgetc(FILE *stream)}
+\fdesc{Leggono un singolo byte da uno \textit{stream}.}
+\fdecl{int getchar(void)}
+\fdesc{Legge un byte dallo \textit{standard input}.}
+}
+
+{Le funzioni ritornano il byte letto in caso di successo e \val{EOF} per un
+ errore o se si arriva alla fine del file.}
+\end{funcproto}
+
+La funzione \func{getc} legge un byte da \param{stream} e lo restituisce come
+intero, ed in genere è implementata come una macro per cui può avere
+\itindex{side~effects} \textit{side effects}, mentre \func{fgetc} è assicurato
+essere sempre una funzione. Infine \func{getchar} è equivalente a
+\code{getc(stdin)}.
A parte \func{getchar}, che si usa in genere per leggere un carattere da
tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
\funcd{getwchar}, che invece di un carattere di un byte restituiscono un
carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
è:
-\begin{functions}
- \headdecl{stdio.h}
- \headdecl{wchar.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 \code{getwc(stdin)}.
-
- \bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
- caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fhead{wchar.h}
+\fdecl{wint\_t getwc(FILE *stream)}
+\fdecl{wint\_t fgetwc(FILE *stream)}
+\fdesc{Leggono un carattere da uno \textit{stream}.}
+\fdecl{wint\_t getwchar(void)}
+\fdesc{Legge un carattere dallo \textit{standard input}.}
+}
+
+{Le funzioni ritornano il carattere letto in caso di successo e \val{WEOF} per
+ un errore o se si arriva alla fine del file.}
+\end{funcproto}
+
+La funzione \func{getwc} legge un carattere esteso da \param{stream} e lo
+restituisce come intero, ed in genere è implementata come una macro, mentre
+\func{fgetwc} è assicurata essere sempre una funzione. Infine \func{getwchar}
+è equivalente a \code{getwc(stdin)}.
+
Per scrivere un carattere si possono usare tre funzioni, analoghe alle
precedenti usate per leggere: \funcd{putc}, \funcd{fputc} e \funcd{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(int c, FILE *stream)} Scrive il carattere \param{c} su
- \param{stream}. È una sempre una funzione.
-
- \funcdecl{int putchar(int c)} Equivalente a \code{putc(stdout)}.
-
- \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 è \val{EOF}.}
-\end{functions}
-
-Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
-come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
-un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
-caso di errore o fine del file il valore di ritorno è \val{EOF}.
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int putc(int c, FILE *stream)}
+\fdecl{int fputc(int c, FILE *stream)}
+\fdesc{Scrive un byte su uno \textit{stream}.}
+\fdecl{int putchar(int c)}
+\fdesc{Scrive un byte sullo \textit{standard output}.}
+}
+
+{Le funzioni ritornano il valore del byte scritto in caso di successo e
+ \val{EOF} per un errore.}
+\end{funcproto}
+
+La funzione \func{putc} scrive un byte su \param{stream} e lo restituisce come
+intero, ed in genere è implementata come una macro, mentre \func{fputc} è
+assicurata essere sempre una funzione. Infine \func{putchar} è equivalente a
+\code{putc(stdout)}. Tutte queste funzioni scrivono sempre un byte alla
+volta, anche se prendono come argomento un \ctyp{int} (che pertanto deve
+essere ottenuto con un cast da un \ctyp{unsigned char}). Anche il valore di
+ritorno è sempre un intero; in caso di errore o fine del file il valore di
+ritorno è \val{EOF}.
Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
provvedono come estensione, per ciascuna delle funzioni precedenti,
Per compatibilità con SVID sono inoltre provviste anche due funzioni,
\funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
(cioè due byte in una volta); 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 \val{EOF}
- in caso di errore o di fine del file.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{getw(FILE *stream)}
+\fdesc{Legge una parola da uno \textit{stream}.}
+\fdecl{int putw(int w, FILE *stream)}
+\fdesc{Scrive una parola su uno \textit{stream}.}
+}
+
+{Le funzioni ritornano la parola letta o scritta in caso di successo e
+ \val{EOF} per un errore.}
+\end{funcproto}
Le funzioni leggono e scrivono una \textit{word} di due byte, usando comunque
una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
disponibile per una lettura successiva; la funzione che inverte la
lettura si chiama \funcd{ungetc} ed il suo prototipo è:
-\begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
- Rimanda indietro il carattere \param{c}, con un cast a \ctyp{unsigned
- char}, sullo \textit{stream} \param{stream}.
-
- \bodydesc{La funzione ritorna \param{c} in caso di successo e
- \val{EOF} in caso di errore.}
-\end{prototype}
-\noindent benché lo standard ANSI C preveda che l'operazione possa
-essere ripetuta per un numero arbitrario di caratteri, alle
-implementazioni è richiesto di garantire solo un livello; questo è
-quello che fa la \acr{glibc}, che richiede che avvenga un'altra
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int ungetc(int c, FILE *stream)}
+\fdesc{Manda indietro un byte su uno \textit{stream}.}
+}
+
+{La funzione ritorna il byte inviato in caso di successo e \val{EOF} per un
+ errore.}
+\end{funcproto}
+
+La funzione rimanda indietro il carattere \param{c}, con un cast a
+\ctyp{unsigned char}, sullo \textit{stream} \param{stream}. Benché lo standard
+ANSI C preveda che l'operazione possa essere ripetuta per un numero arbitrario
+di caratteri, alle implementazioni è richiesto di garantire solo un livello;
+questo è quello che fa la \acr{glibc}, che richiede che avvenga un'altra
operazione fra due \func{ungetc} successive.
Non è necessario che il carattere che si manda indietro sia l'ultimo che
Le funzioni previste dallo standard ANSI C per leggere una linea sono
sostanzialmente due, \funcd{gets} e \funcd{fgets}, i cui 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 l'indirizzo \param{string} in caso
- di successo o \val{NULL} in caso di errore.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{char *gets(char *string)}
+\fdesc{Legge una linea di testo dallo \textit{standard input}.}
+\fdecl{char *fgets(char *string, int size, FILE *stream)}
+\fdesc{Legge una linea di testo da uno \textit{stream}.}
+}
+
+{Le funzioni ritornano l'indirizzo della stringa con la linea di testo letta o
+ scritta in caso di successo e \val{NULL} per un errore.}
+\end{funcproto}
Entrambe le funzioni effettuano la lettura (dal file specificato \func{fgets},
dallo standard input \func{gets}) di una linea di caratteri (terminata dal
Per la scrittura di una linea lo standard ANSI C prevede altre due
funzioni, \funcd{fputs} e \funcd{puts}, analoghe a quelle di lettura, i
rispettivi prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{int puts(const char *string)} Scrive su \var{stdout} la
- linea \param{string}.
-
- \funcdecl{int fputs(const char *string, FILE *stream)} Scrive su
- \param{stream} la linea \param{string}.
-
- \bodydesc{Le funzioni restituiscono un valore non negativo in caso di
- successo o \val{EOF} in caso di errore.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int puts(char *string)}
+\fdesc{Scrive una linea di testo sullo \textit{standard output}.}
+\fdecl{int fputs(char *string, int size, FILE *stream)}
+\fdesc{Scrive una linea di testo su uno \textit{stream}.}
+}
+
+{Le funzioni ritornano un valore non negativo in caso di successo e \val{EOF}
+ per un errore.}
+\end{funcproto}
+
+La funzione \func{puts} scrive una linea di testo mantenuta
+all'indirizzo \param{string} sullo \textit{standard output} mentre \func{puts}
+la scrive sul file indicato da \param{stream}.
Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
problemi di \func{gets} ed è in genere la forma più immediata per scrivere
linea esistono delle estensioni per leggere e scrivere linee di caratteri
estesi, le funzioni in questione sono \funcd{fgetws} e \funcd{fputws} ed i
loro prototipi sono:
-\begin{functions}
- \headdecl{wchar.h}
- \funcdecl{wchar\_t *fgetws(wchar\_t *ws, int n, FILE *stream)}
- Legge un massimo di \param{n} caratteri estesi dal file
- \param{stream} al buffer \param{ws}.
-
- \funcdecl{int fputws(const wchar\_t *ws, FILE *stream)} Scrive la
- linea \param{ws} di caratteri estesi sul file \param{stream}.
-
- \bodydesc{Le funzioni ritornano rispettivamente \param{ws} o un numero
- non negativo in caso di successo e \val{NULL} o \val{EOF} in
- caso di errore o fine del file.}
-\end{functions}
-
-Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
+
+\begin{funcproto}{
+\fhead{wchar.h}
+\fdecl{wchar\_t *fgetws(wchar\_t *ws, int n, FILE *stream)}
+\fdesc{Legge una stringa di carattere estesi da uno \textit{stream}.}
+\fdecl{int fputws(const wchar\_t *ws, FILE *stream)}
+\fdesc{Scrive una stringa di carattere estesi da uno \textit{stream}.}
+}
+
+{Le funzioni ritornano rispettivamente l'indirizzo della stringa o un non
+ negativo in caso di successo e \val{NULL} o \val{EOF} per un errore o per la
+ fine del file.}
+\end{funcproto}
+
+
+La funzione \func{fgetws} legge un massimo di \param{n} caratteri estesi dal
+file \param{stream} al buffer \param{ws}, mentre la funzione \func{fputws}
+scrive la linea \param{ws} di caratteri estesi sul file \param{stream}. Il
+comportamento di queste due funzioni è identico a quello di \func{fgets} e
\func{fputs}, a parte il fatto che tutto (numero di caratteri massimo,
terminatore della stringa, newline) è espresso in termini di caratteri estesi
anziché di normali caratteri ASCII.
\headfile{stdio.h}. La prima delle due, \funcd{getline}, serve per leggere una
linea terminata da un newline, esattamente allo stesso modo di \func{fgets},
il suo prototipo è:
-\begin{prototype}{stdio.h}
- {ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
- dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
- riallocandolo se necessario (l'indirizzo del buffer e la sua dimensione
- vengono sempre riscritte).
-
- \bodydesc{La funzione ritorna il numero di caratteri letti in caso di
- successo e -1 in caso di errore o di raggiungimento della fine del
- file.}
-\end{prototype}
-
-La funzione permette di eseguire una lettura senza doversi preoccupare della
-eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
-argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
-linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
-\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
-locale); come secondo argomento la funzione vuole l'indirizzo della variabile
-contenente le dimensioni del buffer suddetto.
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{ssize\_t getline(char **buffer, size\_t *n, FILE *stream)}
+\fdesc{Legge una riga da uno \textit{stream}.}
+}
+
+{La funzione ritorna il numero di caratteri letti in caso di successo e $-1$
+ per un errore o per il raggiungimento della fine del file.}
+\end{funcproto}
+
+La funzione legge una linea dal file \param{stream} copiandola sul buffer
+indicato da \param{buffer} riallocandolo se necessario (l'indirizzo del buffer
+e la sua dimensione vengono sempre riscritte). Permette così di eseguire una
+lettura senza doversi preoccupare della eventuale lunghezza eccessiva della
+stringa da leggere. Essa prende come primo argomento l'indirizzo del puntatore
+al buffer su cui si vuole copiare la linea. Quest'ultimo \emph{deve} essere
+stato allocato in precedenza con una \func{malloc} (non si può passare
+l'indirizzo di un puntatore ad una variabile locale); come secondo argomento
+la funzione vuole l'indirizzo della variabile contenente le dimensioni del
+buffer suddetto.
Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
La seconda estensione GNU è una generalizzazione di \func{getline} per
poter usare come separatore un carattere qualsiasi, la funzione si
chiama \funcd{getdelim} ed il suo prototipo è:
-\begin{prototype}{stdio.h}
-{ssize\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)}
- Identica a \func{getline} solo che usa \param{delim} al posto del
- carattere di newline come separatore di linea.
-\end{prototype}
-
-Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
-può essere implementata da questa passando \verb|'\n'| come valore di
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{size\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)}
+\fdesc{Legge da uno \textit{stream} una riga delimitata da un carattere
+ scelto.}
+}
+
+{La funzione ha gli stessi valori di ritorno e gli stessi errori di
+ \func{getline}.}
+\end{funcproto}
+
+La funzione è identica a \func{getline} solo che usa \param{delim} al posto
+del carattere di newline come separatore di linea. Il comportamento di
+\func{getdelim} è identico a quello di \func{getline} (che può essere
+implementata da questa passando \verb|'\n'| come valore di
\param{delim}).
L'output formattato viene eseguito con una delle 13 funzioni della famiglia
\func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
\funcd{sprintf}, i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
- \funcdecl{int printf(const char *format, ...)} Stampa su \file{stdout}
- gli argomenti, secondo il formato specificato da \param{format}.
-
- \funcdecl{int fprintf(FILE *stream, const char *format, ...)} Stampa
- su \param{stream} gli argomenti, secondo il formato specificato da
- \param{format}.
-
- \funcdecl{int sprintf(char *str, const char *format, ...)} Stampa
- sulla stringa \param{str} gli argomenti, secondo il formato
- specificato da \param{format}.
-
- \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
-\end{functions}
-\noindent le prime due servono per stampare su file (lo standard output o
-quello specificato) la terza permette di stampare su una stringa, in genere
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int printf(const char *format, ...)}
+\fdesc{Scrive una stringa formattata sullo \textit{standard output}.}
+\fdecl{int fprintf(FILE *stream, const char *format, ...)}
+\fdesc{Scrive una stringa formattata su uno \textit{stream}.}
+\fdecl{int sprintf(char *str, const char *format, ...)}
+\fdesc{Scrive una stringa formattata su un buffer.}
+}
+
+{Le funzioni ritornano il numero di caratteri scritti in caso di successo e un
+ valore negativo per un errore.}
+\end{funcproto}
+
+
+Le funzioni usano la stringa \param{format} come indicatore del formato con
+cui dovrà essere scritto il contenuto degli argomenti, il cui numero
+\index{funzioni!variadic} è variabile e dipende dal formato stesso.
+
+Le prime due servono per scrivere su file (lo \textit{standard output} o
+quello specificato) la terza permette di scrivere su una stringa, in genere
l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
possibili \itindex{buffer~overflow} \textit{buffer overflow}; per questo
motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
è:
-\begin{prototype}{stdio.h}
-{snprintf(char *str, size\_t size, const char *format, ...)}
- Identica a \func{sprintf}, ma non scrive su \param{str} più di
- \param{size} caratteri.
-\end{prototype}
-
-La parte più complessa delle funzioni di scrittura formattata è il formato
-della stringa \param{format} che indica le conversioni da fare, e da cui
-deriva anche il numero degli argomenti che dovranno essere passati a seguire
-(si noti come tutte queste funzioni siano \index{funzioni!variadic}
-\textit{variadic}, prendendo un numero di argomenti variabile che dipende
-appunto da quello che si è specificato in \param{format}).
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{snprintf(char *str, size\_t size, const char *format, ...)}
+\fdesc{Scrive una stringa formattata su un buffer.}
+}
+
+{La funzione ha lo stesso valore di ritorno e gli stessi errori di
+ \func{sprintf}.}
+\end{funcproto}
+
+La funzione è identica a \func{sprintf}, ma non scrive su \param{str} più di
+\param{size} caratteri. La parte più complessa delle funzioni di scrittura
+formattata è il formato della stringa \param{format} che indica le conversioni
+da fare, e da cui deriva anche il numero degli argomenti che dovranno essere
+passati a seguire (si noti come tutte queste funzioni siano
+\index{funzioni!variadic} \textit{variadic}, prendendo un numero di argomenti
+variabile che dipende appunto da quello che si è specificato
+in \param{format}).
\begin{table}[htb]
\centering
\end{table}
Una versione alternativa delle funzioni di output formattato, che permettono
-di usare il puntatore ad una lista variabile \index{funzioni!variadic} di
-argomenti (vedi sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf},
-\funcd{vfprintf} e \funcd{vsprintf}, i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{int vprintf(const char *format, va\_list ap)} Stampa su
- \var{stdout} gli argomenti della lista \param{ap}, secondo il formato
- specificato da \param{format}.
-
- \funcdecl{int vfprintf(FILE *stream, const char *format, va\_list ap)}
- Stampa su \param{stream} gli argomenti della lista \param{ap}, secondo il
- formato specificato da \param{format}.
-
- \funcdecl{int vsprintf(char *str, const char *format, va\_list ap)} Stampa
- sulla stringa \param{str} gli argomenti della lista \param{ap}, secondo il
- formato specificato da \param{format}.
-
- \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
-\end{functions}
-\noindent con queste funzioni diventa possibile selezionare gli argomenti che
-si vogliono passare ad una funzione di stampa, passando direttamente la lista
+di usare il puntatore ad una lista variabile di argomenti (vedi
+sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf}, \funcd{vfprintf} e
+\funcd{vsprintf}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int vprintf(const char *format, va\_list ap)}
+\fdesc{Scrive una stringa formattata sullo \textit{standard output}.}
+\fdecl{int vfprintf(FILE *stream, const char *format, va\_list ap)}
+\fdesc{Scrive una stringa formattata su un \textit{stream}.}
+\fdecl{int vsprintf(char *str, const char *format, va\_list ap)}
+\fdesc{Scrive una stringa formattata su un buffer.}
+}
+
+{Le funzioni ritornano il numero di caratteri scritti in caso di successo e un
+ valore negativo per un errore.}
+\end{funcproto}
+
+Con queste funzioni diventa possibile selezionare gli argomenti che si
+vogliono passare ad una funzione di stampa, passando direttamente la lista
tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
variabile\index{funzioni!variadic} degli argomenti dovrà essere opportunamente
trattata (l'argomento è esaminato in sez.~\ref{sec:proc_variadic}), e dopo
Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
\funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
scritti sulla stringa di destinazione:
-\begin{prototype}{stdio.h}
-{vsnprintf(char *str, size\_t size, const char *format, va\_list ap)}
- Identica a \func{vsprintf}, ma non scrive su \param{str} più di
- \param{size} caratteri.
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{vsnprintf(char *str, size\_t size, const char *format, va\_list ap)}
+\fdesc{Scrive una stringa formattata su un buffer.}
+}
+
+{La funzione ha lo stesso valore di ritorno e gli stessi errori di
+ \func{vsprintf}.}
+\end{funcproto}
+
\noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
overflow.
-Per eliminare alla radice questi problemi, le \acr{glibc} supportano una
+Per eliminare alla radice questi problemi, la \acr{glibc} supporta una
specifica estensione GNU che alloca dinamicamente tutto lo spazio necessario;
l'estensione si attiva al solito definendo \macro{\_GNU\_SOURCE}, le due
funzioni sono \funcd{asprintf} e \funcd{vasprintf}, ed i rispettivi prototipi
sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{int asprintf(char **strptr, const char *format, ...)} Stampa gli
- argomenti specificati secondo il formato specificato da \param{format} su
- una stringa allocata automaticamente all'indirizzo \param{*strptr}.
-
- \funcdecl{int vasprintf(char **strptr, const char *format, va\_list ap)}
- Stampa gli argomenti della lista \param{ap} secondo il formato specificato
- da \param{format} su una stringa allocata automaticamente all'indirizzo
- \param{*strptr}.
-
- \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int asprintf(char **strptr, const char *format, ...)}
+\fdecl{int vasprintf(char **strptr, const char *format, va\_list ap)}
+\fdesc{Scrive una stringa formattata su un buffer.}
+}
+
+{Le funzioni hanno lo stesso valore di ritorno e gli stessi errori di
+ \func{vsprintf}.}
+\end{funcproto}
+
Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
l'output formattato, l'input formattato viene eseguito con le funzioni della
famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
\funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
- scansione di \file{stdin} cercando una corrispondenza di quanto letto con il
- formato dei dati specificato da \param{format}, ed effettua le relative
- conversione memorizzando il risultato negli argomenti seguenti.
-
- \funcdecl{int fscanf(FILE *stream, const char *format, ...)} Analoga alla
- precedente, ma effettua la scansione su \param{stream}.
-
- \funcdecl{int sscanf(char *str, const char *format, ...)} Analoga alle
- precedenti, ma effettua la scansione dalla stringa \param{str}.
-
- \bodydesc{Le funzioni ritornano il numero di elementi assegnati. Questi
- possono essere in numero inferiore a quelli specificati, ed anche zero.
- Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
- di errore o fine del file viene invece restituito \val{EOF}.}
-\end{functions}
-\noindent e come per le analoghe funzioni di scrittura esistono le relative
-\funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un puntatore ad
-una lista di argomenti.
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int scanf(const char *format, ...)}
+\fdesc{Esegue la scansione di dati dallo \textit{standard input}.}
+\fdecl{int fscanf(FILE *stream, const char *format, ...)}
+\fdesc{Esegue la scansione di dati da uno \textit{stream}. }
+\fdecl{int sscanf(char *str, const char *format, ...)}
+\fdesc{Esegue la scansione di dati da un buffer.}
+}
+
+{La funzione ritorna il numero di elementi assegnati in caso di successo e
+ \val{EOF} per un errore o se si raggiunta la fine del file.}
+\end{funcproto}
+
+Le funzioni eseguono una scansione della rispettiva fonte di input cercando
+una corrispondenza di quanto letto con il formato dei dati specificato
+da \param{format}, ed effettua le relative conversione memorizzando il
+risultato negli argomenti seguenti, il cui numero è variabile e dipende dal
+valore di \param{format}. Come per le analoghe funzioni di scrittura esistono
+le relative \funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un
+puntatore ad una lista di argomenti. Le funzioni ritornano il numero di
+elementi assegnati. Questi possono essere in numero inferiore a quelli
+specificati, ed anche zero. Quest'ultimo valore significa che non si è trovata
+corrispondenza.
Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
puntatori alle variabili che dovranno contenere le conversioni; questo è un
sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
funzioni tradizionali usate per il riposizionamento della posizione in uno
\textit{stream} sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{int fseek(FILE *stream, long offset, int whence)} Sposta la
- posizione nello \textit{stream} secondo quanto specificato
- tramite \param{offset} e \param{whence}.
- \funcdecl{void rewind(FILE *stream)} Riporta la posizione nello
- \textit{stream} all'inizio del file.
-\end{functions}
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fseek(FILE *stream, long offset, int whence)}
+\fdesc{Sposta la posizione nello \textit{stream}.}
+\fdecl{void rewind(FILE *stream)}
+\fdesc{Riporta la posizione nello \textit{stream} all'inizio del file.}
+}
+
+{La funzione \func{fseek} ritorna $0$ in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori di \func{lseek},
+ \func{rewind} non ritorna nulla e non ha condizioni di errore.}
+\end{funcproto}
L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
particolare \param{whence} assume gli stessi valori già visti in
sez.~\ref{sec:file_lseek}. La funzione restituisce 0 in caso di successo e -1
in caso di errore. La funzione \func{rewind} riporta semplicemente la
-posizione corrente all'inizio dello \textit{stream}, ma non esattamente
+posizione corrente all'inizio dello \textit{stream}, ma non è esattamente
equivalente ad una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono
cancellati anche i flag di errore e fine del file.
Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
cui prototipo è:
-\begin{prototype}{stdio.h}{long ftell(FILE *stream)}
- Legge la posizione attuale nello \textit{stream} \param{stream}.
-
- \bodydesc{La funzione restituisce la posizione corrente, o -1 in caso
- di fallimento, che può esser dovuto sia al fatto che il file non
- supporta il riposizionamento che al fatto che la posizione non può
- essere espressa con un \ctyp{long int}}
-\end{prototype}
-\noindent la funzione restituisce la posizione come numero di byte
-dall'inizio dello \textit{stream}.
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{long ftell(FILE *stream)}
+\fdesc{Legge la posizione attuale nello \textit{stream}.}
+}
+
+{La funzione ritorna la posizione corrente in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà i valori di \func{lseek}.}
+\end{funcproto}
+
+
+La funzione restituisce la posizione come numero di byte dall'inizio dello
+\textit{stream}.
Queste funzioni esprimono tutte la posizione nel file come un \ctyp{long int}.
Dato che (ad esempio quando si usa un filesystem indicizzato a 64 bit) questo
può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
\funcd{fgetpos} e \funcd{fsetpos}, che invece usano il nuovo tipo
\type{fpos\_t}, ed i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{int fsetpos(FILE *stream, fpos\_t *pos)} Imposta la posizione
- corrente nello \textit{stream} \param{stream} al valore specificato
- da \param{pos}.
-
- \funcdecl{int fgetpos(FILE *stream, fpos\_t *pos)} Legge la posizione
- corrente nello \textit{stream} \param{stream} e la scrive in \param{pos}.
-
- \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
- errore.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fsetpos(FILE *stream, fpos\_t *pos)}
+\fdesc{.}
+\fdecl{int fgetpos(FILE *stream, fpos\_t *pos)}
+\fdesc{.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori di \func{lseek}.}
+\end{funcproto}
In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni
\func{fseeko} e \func{ftello}, che sono assolutamente identiche alle
attributi dei file. Però, dato che ogni \textit{stream} si appoggia ad un file
descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
il prototipo della funzione è:
-\begin{prototype}{stdio.h}{int fileno(FILE *stream)}
- Legge il file descriptor sottostante lo \textit{stream} \param{stream}.
-
- \bodydesc{Restituisce il numero del file descriptor in caso di successo, e
- -1 qualora \param{stream} non sia valido, nel qual caso imposta
- \var{errno} a \errval{EBADF}.}
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fileno(FILE *stream)}
+\fdesc{Legge il file descriptor sottostante lo \textit{stream}.}
+}
+
+{La funzione ritorna il numero del file descriptor in caso di successo e $-1$
+ per un errore, nel qual caso \var{errno} assumerà il valore \errval{EBADF}
+ se \param{stream} non è valido.}
+\end{funcproto}
+
\noindent ed in questo modo diventa possibile usare direttamente \func{fcntl}.
Questo permette di accedere agli attributi del file descriptor sottostante lo
rispetto al semplice puntatore allo \textit{stream}; questo può essere evitato
con le due funzioni \funcd{\_\_freadable} e \funcd{\_\_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}
+
+\begin{funcproto}{
+\fhead{stdio\_ext.h}
+\fdecl{int \_\_freadable(FILE *stream)}
+\fdesc{Controlla se uno \textit{stream} consente la lettura.}
+\fdecl{int \_\_fwritable(FILE *stream)}
+\fdesc{Controlla se uno \textit{stream} consente la scrittura.}
+}
+
+{Le funzioni ritornano un valore diverso da $0$ se l'operazione richiesta è
+ consentita, non sono previste condizioni di errore.}
+\end{funcproto}
+
\noindent che permettono di ottenere questa informazione.
La conoscenza dell'ultima operazione effettuata su uno \textit{stream} aperto
è utile in quanto permette di trarre conclusioni sullo stato del buffer e del
suo contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
servono a tale scopo, 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}
+\begin{funcproto}{
+\fhead{stdio\_ext.h}
+\fdecl{int \_\_freading(FILE *stream)}
+\fdesc{Controlla l'ultima operazione di lettura.}
+\fdecl{int \_\_fwriting(FILE *stream)}
+\fdesc{Controlla l'ultima operazione di scrittura.}
+}
+
+{Le funzioni ritornano un valore diverso da $0$ se l'operazione richiesta è
+ consentita, non sono previste condizioni di errore.}
+\end{funcproto}
+
+La funzione \func{\_\_freading} restituisce un valore diverso da zero
+se \param{stream} è aperto in sola lettura o se l'ultima operazione è stata di
+lettura mentre \func{\_\_fwriting} restituisce un valore diverso da zero
+se \param{stream} è aperto in sola scrittura o se l'ultima operazione è stata
+di scrittura.
Le due funzioni permettono di determinare di che tipo è stata l'ultima
operazione eseguita su uno \textit{stream} aperto in lettura/scrittura;
operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
suo prototipo è:
-\begin{prototype}{stdio.h}{int setvbuf(FILE *stream, char *buf, int mode,
- size\_t size)}
-
- Imposta la bufferizzazione dello \textit{stream} \param{stream} nella
- modalità indicata da \param{mode}, usando \param{buf} come buffer di
- lunghezza
- \param{size}.
-
- \bodydesc{Restituisce zero in caso di successo, ed un valore qualunque in
- caso di errore, nel qual caso \var{errno} viene impostata opportunamente.}
-\end{prototype}
-
-La funzione permette di controllare tutti gli aspetti della bufferizzazione;
-l'utente può specificare un buffer da usare al posto di quello allocato dal
-sistema passandone alla funzione l'indirizzo in \param{buf} e la dimensione in
-\param{size}.
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int setvbuf(FILE *stream, char *buf, int mode, size\_t size)}
+\fdesc{Imposta la bufferizzazione dello \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e un altro valore qualunque per
+ un errore, nel qual caso \var{errno} assumerà un valore appropriato.}
+\end{funcproto}
+
+
+La funzione imposta la bufferizzazione dello \textit{stream} \param{stream}
+nella modalità indicata da \param{mode}, usando \param{buf} come buffer di
+lunghezza \param{size} e permette di controllare tutti gli aspetti della
+bufferizzazione; l'utente può specificare un buffer da usare al posto di
+quello allocato dal sistema passandone alla funzione l'indirizzo
+in \param{buf} e la dimensione in \param{size}.
Ovviamente se si usa un buffer specificato dall'utente questo deve essere
stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
\funcd{setbuffer} e \funcd{setlinebuf}; i loro prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{void setbuf(FILE *stream, char *buf)} Disabilita la
- bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
- come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
-
- \funcdecl{void setbuffer(FILE *stream, char *buf, size\_t size)} Disabilita
- la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
- come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
-
- \funcdecl{void setlinebuf(FILE *stream)} Pone lo \textit{stream} in modalità
- \textit{line buffered}.
-\end{functions}
-\noindent tutte queste funzioni sono realizzate con opportune chiamate a
-\func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
-BSD. Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
- queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{void setbuf(FILE *stream, char *buf)}
+\fdecl{void setbuffer(FILE *stream, char *buf, size\_t size)}
+\fdesc{Impostano il buffer per uno \textit{stream}.}
+\fdecl{void setlinebuf(FILE *stream)}
+\fdesc{Porta uno \textit{stream} in modalità \textit{line buffered}.}
+}
+
+{Le funzioni non ritornano niente e non hanno condizioni di errore.}
+\end{funcproto}
+
+
+La funzione \func{setbuf} disabilita la bufferizzazione se \param{buf} è
+\val{NULL}, altrimenti usa \param{buf} come buffer di dimensione
+\const{BUFSIZ} in modalità \textit{fully buffered}, mentre \func{setbuffer}
+disabilita la bufferizzazione se \param{buf} è \val{NULL}, altrimenti
+usa \param{buf} come buffer di dimensione \param{size} in modalità
+\textit{fully buffered}. Tutte queste funzioni sono realizzate con opportune
+chiamate a \func{setvbuf} e sono definite solo per compatibilità con le
+vecchie librerie BSD.
+
+Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
+ queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
\funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
di uno \textit{stream}; i cui prototipi sono:
-\begin{functions}
- \headdecl{stdio\_ext.h}
-
- \funcdecl{int \_\_flbf(FILE *stream)} Restituisce un valore diverso da zero
- se \param{stream} è in modalità \textit{line buffered}.
-
- \funcdecl{size\_t \_\_fbufsize(FILE *stream)} Restituisce le dimensioni del
- buffer di \param{stream}.
-\end{functions}
+
+\begin{funcproto}{
+\fhead{stdio\_ext.h}
+\fdecl{size\_t \_\_fbufsize(FILE *stream)}
+\fdesc{Restituisce le dimensioni del buffer di uno \textit{stream}.}
+\fdecl{int \_\_flbf(FILE *stream)}
+\fdesc{Controlla la modalità di bufferizzazione di uno \textit{stream}.}
+}
+
+{Le funzioni ritornano rispettivamente la dimensione del buffer o un valore
+ non nullo se lo \textit{stream} è in modalità \textit{line-buffered}, non
+ sono previste condizioni di errore.}
+\end{funcproto}
Come già accennato, indipendentemente dalla modalità di bufferizzazione
scelta, si può forzare lo scarico dei dati sul file con la funzione
\funcd{fflush}, il suo prototipo è:
-\begin{prototype}{stdio.h}{int fflush(FILE *stream)}
-
- Forza la scrittura di tutti i dati bufferizzati dello
- \textit{stream} \param{stream}.
-
- \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
- errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
- aperto o non è aperto in scrittura, o ad uno degli errori di
- \func{write}.}
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fflush(FILE *stream)}
+\fdesc{Forza la scrittura dei dati bufferizzati di uno \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e \val{EOF} per un errore, nel
+ qual caso \var{errno} assumerà il valore \errval{EBADF} se \param{stream}
+ non è aperto o non è aperto in scrittura, o ad uno degli errori di
+ \func{write}.}
+\end{funcproto}
+
\noindent anche di questa funzione esiste una analoga
\func{fflush\_unlocked}\footnote{accessibile definendo \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
line buffered; per questo motivo le \acr{glibc} supportano una estensione di
Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
-\begin{prototype}{stdio-ext.h}{void \_flushlbf(void)}
- Forza la scrittura di tutti i dati bufferizzati degli \textit{stream} in
- modalità line buffered.
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio-ext.h}
+\fdecl{void \_flushlbf(void)}
+\fdesc{Forza la scrittura dei dati bufferizzati degli \textit{stream} in
+ modalità \textit{line buffered}.}
+}
+
+{La funzione non ritorna nulla e non presenta condizioni di errore.}
+\end{funcproto}
Si ricordi comunque che lo scarico dei dati dai buffer effettuato da queste
funzioni non comporta la scrittura di questi su disco; se si vuole che il
Infine esistono anche circostanze in cui si vuole scartare tutto l'output
pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
-\begin{prototype}{stdio.h}{int fpurge(FILE *stream)}
-
- Cancella i buffer di input e di output dello \textit{stream} \param{stream}.
-
- \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
- errore.}
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fpurge(FILE *stream)}
+\fdesc{Cancella i buffer di uno \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e \val{EOF} per un errore.}
+\end{funcproto}
La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
Ci sono comunque situazioni in cui questo non basta, come quando un
\textit{thread} necessita di compiere più di una operazione sullo
\textit{stream} atomicamente, per questo motivo le librerie provvedono anche
-delle funzioni \funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile},
-che permettono la gestione esplicita dei blocchi sugli \textit{stream}; esse
-sono disponibili definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro
-prototipi sono:
-\begin{functions}
- \headdecl{stdio.h}
-
- \funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
- \textit{stream} \param{stream}, bloccandosi se il lock non è disponibile.
-
- \funcdecl{int ftrylockfile(FILE *stream)} Tenta l'acquisizione del lock
- dello \textit{stream} \param{stream}, senza bloccarsi se il lock non è
- disponibile. Ritorna zero in caso di acquisizione del lock, diverso da zero
- altrimenti.
-
- \funcdecl{void funlockfile(FILE *stream)} Rilascia il lock dello
- \textit{stream} \param{stream}.
-\end{functions}
-\noindent con queste funzioni diventa possibile acquisire un blocco ed
-eseguire tutte le operazioni volute, per poi rilasciarlo.
-
-Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
-blocco non sono del tutto indolori, e quando il locking dello \textit{stream}
-non è necessario (come in tutti i programmi che non usano i \textit{thread}),
-tutta la procedura può comportare dei costi pesanti in termini di
-prestazioni. Per questo motivo abbiamo visto come alle usuali funzioni di I/O
-non formattato siano associate delle versioni \code{\_unlocked} (alcune
-previste dallo stesso standard POSIX, altre aggiunte come estensioni dalle
-\acr{glibc}) che possono essere usate quando il locking non serve\footnote{in
- certi casi dette funzioni possono essere usate, visto che sono molto più
- efficienti, anche in caso di necessità di locking, una volta che questo sia
- stato acquisito manualmente.} con prestazioni molto più elevate, dato che
-spesso queste versioni (come accade per \func{getc} e \func{putc}) sono
-realizzate come macro.
+delle funzioni \funcd{flockfile} e \funcd{funlockfile}, che permettono la
+gestione esplicita dei blocchi sugli \textit{stream}; esse sono disponibili
+definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{void flockfile(FILE *stream)}
+\fdesc{Acquisisce il lock su uno \textit{stream}.}
+\fdecl{void funlockfile(FILE *stream)}
+\fdesc{Rilascia il lock su uno \textit{stream}.}
+}
+{Le funzioni non ritornano nulla e non sono previste condizioni di errore.}
+\end{funcproto}
+
+La funzione \func{flockfile} esegue l'acquisizione del lock dello
+\textit{stream} \param{stream}, bloccandosi se il lock non è disponibile,
+mentre \func{funlockfile} rilascia il lock.
+
+Si può poi provare ad acquisire un lock senza bloccarsi con
+\funcd{ftrylockfile}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int ftrylockfile(FILE *stream)}
+\fdesc{Tenta l'acquisizione del lock di uno \textit{stream}.}
+}
+
+{La funzione ritorna $0$ in caso di acquisizione del lock ed un altro valore
+ qualunque altrimenti, non sono previste condizioni di errore.}
+\end{funcproto}
+
+Con queste funzioni diventa possibile acquisire un blocco ed eseguire tutte le
+operazioni volute, per poi rilasciarlo. Ma, vista la complessità delle
+strutture di dati coinvolte, le operazioni di blocco non sono del tutto
+indolori, e quando il locking dello \textit{stream} non è necessario (come in
+tutti i programmi che non usano i \textit{thread}), tutta la procedura può
+comportare dei costi pesanti in termini di prestazioni. Per questo motivo
+abbiamo visto come alle usuali funzioni di I/O non formattato siano associate
+delle versioni \code{\_unlocked} (alcune previste dallo stesso standard POSIX,
+altre aggiunte come estensioni dalle \acr{glibc}) che possono essere usate
+quando il locking non serve\footnote{in certi casi dette funzioni possono
+ essere usate, visto che sono molto più efficienti, anche in caso di
+ necessità di locking, una volta che questo sia stato acquisito manualmente.}
+con prestazioni molto più elevate, dato che spesso queste versioni (come
+accade per \func{getc} e \func{putc}) sono realizzate come macro.
La sostituzione di tutte le funzioni di I/O con le relative versioni
\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
il cui prototipo è:
-\begin{prototype}{stdio\_ext.h}{int \_\_fsetlocking (FILE *stream, int type)}
- Specifica o richiede a seconda del valore di \param{type} la modalità in cui
- le operazioni di I/O su \param{stream} vengono effettuate rispetto
- all'acquisizione implicita del blocco sullo \textit{stream}.
-
- \bodydesc{Restituisce lo stato di locking interno dello \textit{stream} con
- uno dei valori \const{FSETLOCKING\_INTERNAL} o
- \const{FSETLOCKING\_BYCALLER}.}
-\end{prototype}
-
-La funzione imposta o legge lo stato della modalità di operazione di uno
-\textit{stream} nei confronti del locking a seconda del valore specificato
-con \param{type}, che può essere uno dei seguenti:
+
+\begin{funcproto}{
+\fhead{stdio\_ext.h}
+\fdecl{int \_\_fsetlocking (FILE *stream, int type)}
+\fdesc{Specifica se abilitare il locking su uno \textit{stream}.}
+}
+
+{La funzione ritorna stato di locking interno dello \textit{stream}, non sono
+ previste condizioni di errore.}
+\end{funcproto}
+
+La funzione imposta o legge lo stato della modalità in cui le operazioni di
+I/O su \param{stream} vengono effettuate rispetto all'acquisizione implicita
+del locking a seconda del valore specificato con \param{type}, che può essere
+uno dei seguenti:
\begin{basedescript}{\desclabelwidth{4.0cm}}
\item[\const{FSETLOCKING\_INTERNAL}] Lo \textit{stream} userà da ora in poi il
blocco implicito predefinito.
di blocco dello \textit{stream}.
\end{basedescript}
+La funzione, se usata con \const{FSETLOCKING\_QUERY}, non modifica la modalità
+di operazione ma restituisce lo stato di locking interno dello \textit{stream}
+con uno dei valori \const{FSETLOCKING\_INTERNAL} o
+\const{FSETLOCKING\_BYCALLER}.
+
+
% TODO trattare \func{clearerr\_unlocked}
% LocalWords: nell'header stdin shell stdout stderr error freopen flush line
% LocalWords: unbuffered buffered newline fully SVr fopen fdopen POSIX const
% LocalWords: char path int fildes NULL errno malloc fcntl fclose fflush tab
-% LocalWords: dup fifo socket append EXCL ccs IRUSR IWUSR IRGRP IWGRP
+% LocalWords: dup fifo socket append EXCL ccs IRUSR IWUSR IRGRP IWGRP inode fd
% LocalWords: IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
-% LocalWords: sync fcloseall void stdlib of feof ferror clearerr ws
+% LocalWords: sync fcloseall void stdlib of feof ferror clearerr ws VFS table
% LocalWords: unlocked fread fwrite size ptr nmemb nelem gcc padding point str
-% LocalWords: lock thread fgetc getc getchar dell'overhead unsigned ap
-% LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar
+% LocalWords: lock thread fgetc getc getchar dell'overhead unsigned ap process
+% LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar struct
% LocalWords: SVID getw putw parsing peeking ahead ungetc gets fgets string Di
% LocalWords: overflow Aleph stack fputs puts fgetws fputws getline ssize leak
% LocalWords: realloc value result argument memory getdelim delim printf short
% LocalWords: lseek ftell fgetpos fpos fseeko ftello fileno Solaris freadable
% LocalWords: fwritable ext freading fwriting buffering setvbuf BUFSIZ setbuf
% LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
-% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile
-% LocalWords: locking fsetlocking type Virtual operation
-% LocalWords: modification hole functions FSETSIG
-
-
-
+% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile files fig flags
+% LocalWords: locking fsetlocking type Virtual operation dentry unistd sys AT
+% LocalWords: modification hole functions FSETSIG pathname EEXIST CREAT EINTR
+% LocalWords: EISDIR EFBIG EOVERFLOW ELOOP NOFOLLOW ENODEV ENOENT ENOTDIR fork
+% LocalWords: EMFILE ENAMETOOLONG ENFILE ENOMEM ENOSPC EROFS exec access RDWR
+% LocalWords: RDONLY ioctl AND ACCMODE creation Denial Service DoS opendir NFS
+% LocalWords: SOURCE LARGEFILE BITS NOCTTY TRUNC SHLOCK shared EXLOCK race SGI
+% LocalWords: exclusive condition change ASYNC SIGIO CLOEXEC DIRECT NDELAY EIO
+% LocalWords: DSYNC FASYNC IRIX FreeBSD EINVAL client RSYNC creat filedes INCR
+% LocalWords: behind shutdown ESPIPE XTND truncate fallocate count EAGAIN log
+% LocalWords: timerfd Specification pwrite pread define XOPEN EPIPE SIGPIPE at
+% LocalWords: caching cache update bdflush fdatasync fstat oldfd newfd DUPFD
+% LocalWords: openat mkdirat mkdir proc ATFILE dirfd FDCWD utimes lutimes uid
+% LocalWords: utimensat faccessat fchmodat chmod fchownat chown lchown fstatat
+% LocalWords: lstat linkat mknodat mknod readlinkat readlink renameat rename
+% LocalWords: symlinkat symlink unlinkat unlink rmdir mkfifoat mkfifo owner is
+% LocalWords: gid group FOLLOW REMOVEDIR cmd arg flock SETFD GETFD GETFL SETFL
+% LocalWords: GETLK SETLK SETLKW GETOWN PID Signal SIGURG SETOWN GETSIG SETSIG
+% LocalWords: sigaction SIGINFO siginfo SETLEASE lease GETLEASE NOTIFY request
+% LocalWords: everything framebuffer ENOTTY argp CDROM lsattr chattr magic
+% LocalWords: number FIOCLEX FIONCLEX FIOASYNC FIONBIO FIOSETOWN FIOGETOWN
+% LocalWords: FIONREAD epoll FIOQSIZE side effects SAFE BYCALLER QUERY EACCES
+% LocalWords: EBUSY OpenBSD syncfs
+% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK
+% LocalWords: EFAULT
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff