%% fileio.tex (merge fileunix.tex - filestd.tex)
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\chapter{La gestione dell'I/O su file}
\label{cha:file_IO_interface}
-
-Esamineremo in questo capitolo le due interfacce di programmazione che
+Esamineremo in questo capitol le due interfacce di programmazione che
consentono di gestire i dati mantenuti nei file. Cominceremo con quella nativa
-del sistema, detta dei \itindex{file~descriptor} \textit{file descriptor}, che
-viene fornita direttamente dalle \textit{system call} e che non prevede
-funzionalità evolute come la bufferizzazione o funzioni di lettura o scrittura
+del sistema, detta dei \textit{file descriptor}, che viene fornita
+direttamente dalle \textit{system call} e che non prevede funzionalità evolute
+come la bufferizzazione o funzioni di lettura o scrittura
formattata. Esamineremo poi anche l'interfaccia definita dallo standard ANSI
C, che viene chiamata dei \textit{file stream} o anche più brevemente degli
\textit{stream}. Per entrambe dopo una introduzione alle caratteristiche
Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
-tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
-serie di \textit{system call} che consentono di operare sui file in maniera
-generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
-file nel precedente capitolo, vedremo quelle che si applicano al contenuto dei
-file in questa sezione, iniziando con una breve introduzione sull'architettura
-dei \textit{file descriptor} per poi trattare le funzioni di base e le
-modalità con cui consentono di gestire i dati memorizzati sui file.
+tramite il \textit{Virtual File System} una serie di \textit{system call} che
+consentono di operare sui file in maniera generale. Abbiamo trattato quelle
+relative alla gestione delle proprietà dei file nel precedente capitolo,
+vedremo quelle che si applicano al contenuto dei file in questa sezione,
+iniziando con una breve introduzione sull'architettura dei \textit{file
+ descriptor} per poi trattare le funzioni di base e le modalità con cui
+consentono di gestire i dati memorizzati sui file.
\subsection{I \textit{file descriptor}}
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_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.
+sez.~\ref{sec:file_open_close}) che provvederà a localizzare l'\textit{inode}
+del file e inizializzare i puntatori che rendono disponibili le funzioni che
+il 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
-file viene aperto la funzione \func{open} restituisce questo numero, tutte le
-ulteriori operazioni dovranno essere compiute specificando questo stesso
-numero come argomento alle varie funzioni dell'interfaccia.
+intero non negativo, che viene chiamato appunto \textit{file descriptor}.
+Quando un file viene aperto la funzione \func{open} restituisce questo numero,
+tutte le ulteriori operazioni dovranno essere compiute specificando questo
+stesso numero come argomento alle varie funzioni dell'interfaccia.
+
+\itindbeg{process~table}
+\itindbeg{file~table}
Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
kernel gestisce l'interazione fra processi e file. Abbiamo già accennato in
sez.~\ref{sec:proc_hierarchy} come il kernel mantenga un elenco di tutti
-processi nella cosiddetta \itindex{process~table} \textit{process table}. Lo
-stesso, come accennato in sez.~\ref{sec:file_vfs_work}, vale anche per tutti i
-file aperti, il cui elenco viene mantenuto nella cosiddetta
-\itindex{file~table} \textit{file table}.
-
-La \itindex{process~table} \textit{process table} è una tabella che contiene
-una voce per ciascun processo attivo nel sistema. Ciascuna voce è costituita
-dal puntatore a una struttura di tipo \kstruct{task\_struct} nella quale sono
-raccolte tutte le informazioni relative al processo, fra queste informazioni
-c'è anche il puntatore ad una ulteriore struttura di tipo
+processi nella cosiddetta \textit{process table}. Lo stesso, come accennato in
+sez.~\ref{sec:file_vfs_work}, vale anche per tutti i file aperti, il cui
+elenco viene mantenuto nella cosiddetta \textit{file table}.
+
+La \textit{process table} è una tabella che contiene una voce per ciascun
+processo attivo nel sistema. Ciascuna voce è costituita dal puntatore a una
+struttura di tipo \kstruct{task\_struct} nella quale sono raccolte tutte le
+informazioni relative al processo, fra queste informazioni c'è anche il
+puntatore ad una ulteriore struttura di tipo
\kstruct{files\_struct},\footnote{la definizione corrente di questa struttura
si trova nel file \texttt{include/linux/fdtable.h} dei sorgenti del kernel,
quella mostrata in fig.~\ref{fig:file_proc_file} è una versione pesantemente
semplificata.} che contiene le informazioni relative ai file che il processo
ha aperto.
-La \itindex{file~table} \textit{file table} è una tabella che contiene una
-voce per ciascun file che è stato aperto nel sistema. Come accennato in
-sez.~\ref{sec:file_vfs_work} per ogni file aperto viene allocata una struttura
-\kstruct{file} e la \textit{file table} è costituita da un elenco di puntatori
-a ciascuna di queste strutture, che, come illustrato in
-fig.~\ref{fig:kstruct_file}, contengono le informazioni necessarie per la
-gestione dei file, ed in particolare:
+La \textit{file table} è una tabella che contiene una voce per ciascun file
+che è stato aperto nel sistema. Come accennato in sez.~\ref{sec:file_vfs_work}
+per ogni file aperto viene allocata una struttura \kstruct{file} e la
+\textit{file table} è costituita da un elenco di puntatori a ciascuna di
+queste strutture, che, come illustrato in fig.~\ref{fig:kstruct_file},
+contengono le informazioni necessarie per la gestione dei file, ed in
+particolare:
\begin{itemize*}
-\item i flag di stato \itindex{file~status~flag} del file nel campo
- \var{f\_flags}.
+\item i flag di stato del file nel campo \var{f\_flags}.
\item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
\var{f\_pos}.
\item un puntatore alla struttura \kstruct{inode} che identifica
- \itindex{inode} l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in
- realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta
- a sua volta \itindex{inode} all'\textit{inode} passando per la nuova
- struttura del VFS.}
+ l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in realtà passati
+ ad un puntatore ad una struttura \kstruct{dentry} che punta a sua volta
+ all'\textit{inode} passando per la nuova struttura del VFS.}
\item un puntatore \var{f\_op} alla tabella delle funzioni che si possono
usare sul file.\footnote{quelle della struttura \kstruct{file\_operation},
descritte sommariamente in tab.~\ref{tab:file_file_operations}.}
\centering
\includegraphics[width=12cm]{img/procfile}
\caption{Schema della architettura dell'accesso ai file attraverso
- l'interfaccia dei \textit{file descriptor}.}
+ l'interfaccia dei file descriptor.}
\label{fig:file_proc_file}
\end{figure}
In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui
è illustrata questa architettura, ed in cui si sono evidenziate le
-interrelazioni fra la \itindex{file~table} \textit{file table}, la
-\itindex{process~table} \textit{process table} e le varie strutture di dati
-che il kernel mantiene per ciascun file e ciascun processo.
+interrelazioni fra la \textit{file table}, la \textit{process table} e le
+varie strutture di dati che il kernel mantiene per ciascun file e ciascun
+processo.
+
+\itindend{process~table}
Come si può notare alla fine il collegamento che consente di porre in
relazione i file ed i processi è effettuato attraverso i dati mantenuti nella
\begin{itemize*}
\item i flag relativi ai file aperti dal processo.
\item il numero di file aperti dal processo.
-\item una tabella di puntatori alla relativa voce nella \itindex{file~table}
- \textit{file table} per ciascun file aperto.
+\item la \itindex{file~descriptor~table} \textit{file descriptor table}, una
+ tabella con i puntatori, per ciascun file aperto, alla relativa voce nella
+ \textit{file table}.
\end{itemize*}
-In questa infrastruttura un \textit{file descriptor} non è altro che l'intero
-positivo che indicizza quest'ultima tabella, e che consente di recuperare il
-puntatore alla struttura \kstruct{file} corrispondente al file aperto dal
-processo a cui era stato assegnato questo indice. Una volta ottenuta grazie
-al \textit{file descriptor} la struttura \kstruct{file} corrispondente al file
-voluto nella \itindex{file~table} \textit{file table}, il kernel potrà usare
-le funzioni messe disposizione dal VFS per eseguire sul file tutte le
-operazioni necessarie.
+In questa infrastruttura un file descriptor non è altro che l'intero positivo
+che indicizza quest'ultima tabella, e che consente di recuperare il puntatore
+alla struttura \kstruct{file} corrispondente al file aperto dal processo a cui
+era stato assegnato questo indice. Una volta ottenuta grazie al file
+descriptor la struttura \kstruct{file} corrispondente al file voluto nella
+\textit{file table}, il kernel potrà usare le funzioni messe disposizione dal
+VFS per eseguire sul file tutte le operazioni necessarie.
Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo
-\textit{file descriptor} libero nella tabella, e per questo motivo essi
-vengono assegnati in successione tutte le volte che si apre un nuovo file,
-posto che non ne sia stato chiuso nessuno in precedenza.
+file descriptor libero nella tabella, e per questo motivo essi vengono
+assegnati in successione tutte le volte che si apre un nuovo file, posto che
+non ne sia stato chiuso nessuno in precedenza.
+
+\itindbeg{standard~input}
+\itindbeg{standard~output}
+\itindbeg{standard~error}
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
processo si aspetta di avere sempre tre file aperti che, per quanto appena
-detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i
-valori 0, 1 e 2. Il primo file è sempre associato al cosiddetto
-\itindex{standard~input} \textit{standard input}, è cioè il file da cui un
-processo si aspetta di dover leggere i dati in ingresso. Il secondo file è il
-cosiddetto \itindex{standard~output} \textit{standard output}, cioè quello su
-cui ci si aspetta di dover scrivere i dati in uscita. Il terzo è lo
-\itindex{standard~error} \textit{standard error}, su cui vengono scritti i
-dati relativi agli errori.
+detto, avranno come \textit{file descriptor} i valori 0, 1 e 2. Il primo file
+è sempre associato al cosiddetto \textit{standard input}, è cioè il file da
+cui un processo si aspetta di dover leggere i dati in ingresso. Il secondo
+file è il cosiddetto \textit{standard output}, cioè quello su cui ci si
+aspetta di dover scrivere i dati in uscita. Il terzo è lo \textit{standard
+ error}, su cui vengono scritti i dati relativi agli errori.
+
+\itindend{file~descriptor}
+
Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
delle applicazioni, e non aderirvi potrebbe portare a problemi di
\textbf{File} & \textbf{Significato} \\
\hline
\hline
- \const{STDIN\_FILENO} & \textit{file descriptor} dello \textit{standard
- input} \\
- \const{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
- output} \\
- \const{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
- error}\\
+ \constd{STDIN\_FILENO} & file descriptor dello \textit{standard input}.\\
+ \constd{STDOUT\_FILENO} & file descriptor dello \textit{standard output}.\\
+ \constd{STDERR\_FILENO} & file descriptor dello \textit{standard error}.\\
\hline
\end{tabular}
\caption{Costanti definite in \headfile{unistd.h} per i file standard.}
\label{tab:file_std_files}
\end{table}
+\itindend{standard~input}
+\itindend{standard~output}
+\itindend{standard~error}
+
In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa
rispetto a quella usuale della shell, in cui tutti e tre questi file fanno
riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata
-la situazione di un programma in cui lo \itindex{standard~input}
-\textit{standard input} è associato ad un file mentre lo
-\itindex{standard~output} \textit{standard output} e lo
-\itindex{standard~error} \textit{standard error} sono associati ad un altro
-file. Si noti poi come per questi ultimi le strutture \kstruct{file} nella
-\itindex{file~table} \textit{file table}, pur essendo distinte, fanno
-riferimento allo stesso \itindex{inode} \textit{inode}, dato che il file che è
-stato aperto lo stesso. Questo è quello che avviene normalmente quando si apre
-più volte lo stesso file.
-
-Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file
- table} una situazione analoga di quella delle voci di una directory, con la
-possibilità di avere più voci che fanno riferimento allo stesso
-\itindex{inode} \textit{inode}. L'analogia è in realtà molto stretta perché
-quando si cancella un file, il kernel verifica anche che non resti nessun
-riferimento in una una qualunque voce della \itindex{file~table} \textit{file
+la situazione di un programma in cui lo \textit{standard input} è associato ad
+un file mentre lo \textit{standard output} e lo \textit{standard error} sono
+associati ad un altro file. Si noti poi come per questi ultimi le strutture
+\kstruct{file} nella \textit{file table}, pur essendo distinte, fanno
+riferimento allo stesso \textit{inode}, dato che il file che è stato aperto lo
+stesso. Questo è quello che avviene normalmente quando si apre più volte lo
+stesso file.
+
+Si ritrova quindi anche con le voci della \textit{file table} una situazione
+analoga di quella delle voci di una directory, con la possibilità di avere più
+voci che fanno riferimento allo stesso \textit{inode}. L'analogia è in realtà
+molto stretta perché quando si cancella un file, il kernel verifica anche che
+non resti nessun riferimento in una una qualunque voce della \textit{file
table} prima di liberare le risorse ad esso associate e disallocare il
-relativo \itindex{inode} \textit{inode}.
+relativo \textit{inode}.
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
lista, ma restano i limiti imposti dall'amministratore (vedi
sez.~\ref{sec:sys_limits}).
+\itindend{file~table}
\subsection{Apertura, creazione e chiusura di un file}
di gestione dei file, quella che dato un \textit{pathname} consente di
ottenere un file descriptor ``\textsl{aprendo}'' il file
corrispondente,\footnote{è \func{open} che alloca \kstruct{file}, la inserisce
- nella \itindex{file~table} \textit{file table} e crea il riferimento nella
+ nella \textit{file table} e crea il riferimento nella
\kstruct{files\_struct} del processo.} il suo prototipo è:
\begin{funcproto}{
\item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
\param{pathname} non è una directory.
\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.
+ \const{O\_WRONLY} ed il file è una \textit{fifo} che non viene letta da
+ nessun processo o \param{pathname} è un file di dispositivo ma il
+ dispositivo è assente.
\item[\errcode{EPERM}] si è specificato \const{O\_NOATIME} e non si è né
amministratori né proprietari del file.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
essergli assegnati. I valori possibili sono gli stessi già visti in
sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
-comunque filtrati dal valore della \itindex{umask} \textit{umask} (vedi
+comunque filtrati dal valore della \textit{umask} (vedi
sez.~\ref{sec:file_perm_management}) del processo.
La funzione restituisce sempre il primo file descriptor libero, una
caratteristica che permette di prevedere qual è il valore del file descriptor
che si otterrà al ritorno di \func{open}, e che viene spesso usata dalle
applicazioni per sostituire i file corrispondenti ai file standard visti in
-tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo
-\itindex{standard~input} \textit{standard input} e si apre subito dopo un
-nuovo file questo diventerà il nuovo \itindex{standard~input} \textit{standard
- input} dato che avrà il file descriptor 0.
+tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo \textit{standard
+ input} e si apre subito dopo un nuovo file questo diventerà il nuovo
+\textit{standard input} dato che avrà il file descriptor 0.
Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
altro processo (torneremo sul significato della condivisione dei file
esso direttamente tramite il file descriptor, e quanto avviene al
\textit{pathname} con cui lo si è aperto sarà del tutto ininfluente.
+\itindbeg{file~status~flag}
+
Il comportamento della funzione, e le diverse modalità con cui può essere
aperto il file, vengono controllati dall'argomento \param{flags} il cui valore
deve essere indicato come maschera binaria in cui ciascun bit ha un
significato specifico. Alcuni di questi bit vanno anche a costituire i
-cosiddetti \textsl{flag di stato} del file (i cosiddetti
-\itindex{file~status~flag} \textit{file status flags}), che vengono mantenuti
-nel campo \var{f\_flags} della struttura \kstruct{file} che abbiamo riportato
-anche in fig.~\ref{fig:file_proc_file}).
+cosiddetti \textsl{flag di stato} del file (i cosiddetti \textit{file status
+ flags}), che vengono mantenuti nel campo \var{f\_flags} della struttura
+\kstruct{file} che abbiamo riportato anche in fig.~\ref{fig:file_proc_file}).
Ciascun flag viene identificato da una apposita costante, ed il valore
di \param{flags} deve essere specificato come OR aritmetico di queste
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \const{O\_RDONLY} & Apre il file in sola lettura.\\
- \const{O\_WRONLY} & Apre il file in sola scrittura.\\
- \const{O\_RDWR} & Apre il file sia in lettura che in scrittura.\\
+ \constd{O\_RDONLY} & Apre il file in sola lettura.\\
+ \constd{O\_WRONLY} & Apre il file in sola scrittura.\\
+ \constd{O\_RDWR} & Apre il file sia in lettura che in scrittura.\\
\hline
\end{tabular}
\caption{Le tre costanti che identificano le modalità di accesso
sez.~\ref{sec:file_fcntl_ioctl}).}
La modalità di accesso deve sempre essere specificata quando si apre un file,
-il valore indicato in \param{flags} viene salvato nei
-\itindex{file~status~flag} \textit{file status flags}, e può essere riletto
-con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore
-può essere poi ottenuto un AND aritmetico della maschera binaria
-\const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
-definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
-\const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
- definizioni completamente fuori standard, attinenti, insieme a
- \const{O\_EXEC} che permetterebbe l'apertura di un file per l'esecuzione, ad
- un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
- alle definizioni classiche non è comunque il caso di utilizzarle.}
+il valore indicato in \param{flags} viene salvato nei \textit{file status
+ flags}, e può essere riletto con \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore può essere poi ottenuto
+un AND aritmetico della maschera binaria \constd{O\_ACCMODE}, ma non può essere
+modificato. Nella \acr{glibc} sono definite inoltre \constd{O\_READ} come
+sinonimo di \const{O\_RDONLY} e \constd{O\_WRITE} come sinonimo di
+\const{O\_WRONLY}.\footnote{si tratta di definizioni completamente fuori
+ standard, attinenti, insieme a \constd{O\_EXEC} che permetterebbe l'apertura
+ di un file per l'esecuzione, ad un non meglio precisato ``\textit{GNU
+ system}''; pur essendo equivalenti alle definizioni classiche non è
+ comunque il caso di utilizzarle.}
+
+\itindend{file~status~flag}
Il secondo gruppo di flag è quello delle \textsl{modalità di
apertura},\footnote{la pagina di manuale di \func{open} parla di
permettono di specificare alcune delle caratteristiche del comportamento di
\func{open} nel momento in viene eseguita per aprire un file. Questi flag
hanno effetto solo nella chiamata della funzione, non sono memorizzati fra i
-\itindex{file~status~flag} \textit{file status flags} e non possono essere
-riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).
+\textit{file status flags} e non possono essere riletti da \func{fcntl} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}).
\begin{table}[htb]
\centering
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole
+ \constd{O\_CREAT} & Se il file non esiste verrà creato, con le regole
di titolarità del file viste in
sez.~\ref{sec:file_ownership_management}. Se si
imposta questo flag l'argomento \param{mode} deve
essere sempre specificato.\\
- \const{O\_DIRECTORY}& Se \param{pathname} non è una directory la
+ \constd{O\_DIRECTORY}&Se \param{pathname} non è una directory la
chiamata fallisce. Questo flag, introdotto con il
kernel 2.1.126, è specifico di Linux e
serve ad evitare dei possibili
\itindex{Denial~of~Service~(DoS)}
\textit{DoS}\footnotemark quando \func{opendir}
- viene chiamata su una fifo o su un dispositivo
+ viene chiamata su una \textit{fifo} o su un dispositivo
associato ad una unità a nastri. Non viene
usato al di fuori dell'implementazione di
\func{opendir}, ed è utilizzabile soltanto se si è
definita la macro \macro{\_GNU\_SOURCE}.\\
- \const{O\_EXCL} & Deve essere usato in congiunzione con
+ \constd{O\_EXCL} & Deve essere usato in congiunzione con
\const{O\_CREAT} ed in tal caso impone che il file
indicato da \param{pathname} non sia già esistente
(altrimenti causa il fallimento della chiamata con
un errore di \errcode{EEXIST}).\\
- \const{O\_LARGEFILE}& Viene usato sui sistemi a 32 bit per richiedere
+ \constd{O\_LARGEFILE}&Viene usato sui sistemi a 32 bit per richiedere
l'apertura di file molto grandi, la cui
dimensione non è rappresentabile con la versione a
32 bit del tipo \type{off\_t}, utilizzando
delle funzioni che si attiva assegnando a $64$ la
macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
questo flag.\\
- \const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo
+ \constd{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo
di terminale, questo non diventerà il terminale di
controllo, anche se il processo non ne ha ancora
uno (si veda sez.~\ref{sec:sess_ctrl_term}).\\
- \const{O\_NOFOLLOW} & Se \param{pathname} è un collegamento simbolico
+ \constd{O\_NOFOLLOW}& Se \param{pathname} è un collegamento simbolico
la chiamata fallisce. Questa è un'estensione BSD
aggiunta in Linux a partire dal kernel
2.1.126, ed utilizzabile soltanto se si è definita
la macro \macro{\_GNU\_SOURCE}.\\
- \const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
+ \constd{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
ne tronca la lunghezza a zero; con un terminale o
- una fifo viene ignorato, negli altri casi il
+ una \textit{fifo} viene ignorato, negli altri casi il
comportamento non è specificato.\\
\hline
\end{tabular}
\label{tab:open_time_flag}
\end{table}
+
+% TODO: aggiungere O_TMPFILE per la creazione di file temporanei senza che
+% questi appaiano sul filesystem, introdotto con il 3.11, vedi:
+% https://lwn.net/Articles/556512/, http://kernelnewbies.org/Linux_3.11
+% https://lwn.net/Articles/558598/ http://lwn.net/Articles/619146/
+
\footnotetext{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{Denial of
Service}, si chiamano così attacchi miranti ad impedire un servizio
causando una qualche forma di carico eccessivo per il sistema, che resta
Si è riportato in tab.~\ref{tab:open_time_flag} l'elenco dei flag delle
\textsl{modalità di apertura}.\footnote{la \acr{glibc} definisce anche i due
- flag \const{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock} e
- \const{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
+ flag \constd{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock} e
+ \constd{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
sez.~\ref{sec:file_locking}, si tratta di opzioni specifiche di BSD, che non
esistono con Linux.} Uno di questi, \const{O\_EXCL}, ha senso solo se usato
in combinazione a \const{O\_CREAT} quando si vuole creare un nuovo file per
assicurarsi che questo non esista di già, e lo si usa spesso per creare i
-cosiddetti \index{file!di lock} ``\textsl{file di lock}'' (vedi
-sez.~\ref{sec:ipc_file_lock}). Si tenga presente che questa opzione è
-supportata su NFS solo a partire da NFSv3 e con il kernel 2.6, nelle versioni
-precedenti la funzionalità viene emulata controllando prima l'esistenza del
-file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
-dar luogo a una \itindex{race~condition} \textit{race condition}.\footnote{un
- file potrebbe venir creato fra il controllo la successiva apertura con
+cosiddetti ``\textsl{file di lock}'' (vedi sez.~\ref{sec:ipc_file_lock}). Si
+tenga presente che questa opzione è supportata su NFS solo a partire da NFSv3
+e con il kernel 2.6, nelle versioni precedenti la funzionalità viene emulata
+controllando prima l'esistenza del file per cui usarla per creare un file di
+lock potrebbe dar luogo a una \textit{race condition}.\footnote{un file
+ potrebbe venir creato fra il controllo la successiva apertura con
\const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
- nome univoco ed usando la funzione \func{link} per creare il \index{file!di
- lock} file di lock, (vedi sez.~\ref{sec:ipc_file_lock}).}
+ nome univoco ed usando la funzione \func{link} per creare il file di lock,
+ (vedi sez.~\ref{sec:ipc_file_lock}).}
Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
indefinito. Nella creazione di un file con \const{O\_CREAT} occorre sempre
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
- \textit{append mode}. La posizione sul file (vedi
- sez.~\ref{sec:file_lseek}) viene sempre mantenuta
- sulla sua coda, per cui quanto si scrive
- viene sempre aggiunto al contenuto precedente. Con
- NFS questa funzionalità non è supportata
- e viene emulata, per questo possono verificarsi
- \itindex{race~condition} \textit{race
- condition} con una sovrapposizione dei dati se
- più di un processo scrive allo stesso tempo. \\
- \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
+ \constd{O\_APPEND} & Il file viene aperto in \textit{append mode}. La
+ posizione sul file (vedi sez.~\ref{sec:file_lseek})
+ viene sempre mantenuta sulla sua coda, per cui
+ quanto si scrive viene sempre aggiunto al contenuto
+ precedente. Con NFS questa funzionalità non è
+ supportata e viene emulata, per questo possono
+ verificarsi \textit{race condition} con una
+ sovrapposizione dei dati se più di un processo
+ scrive allo stesso tempo.\\
+ \constd{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
sez.~\ref{sec:signal_driven_io}). Quando è
impostato viene generato il segnale \signal{SIGIO}
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. Per
+ e, a partire dal kernel 2.6, anche sulle \textit{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
+ \constd{O\_CLOEXEC}& Attiva la modalità di \textit{close-on-exec} (vedi
sez.~\ref{sec:proc_exec}) sul file. Il flag è
previsto dallo standard POSIX.1-2008, ed è stato
introdotto con il kernel 2.6.23 per evitare una
- \itindex{race~condition} \textit{race condition}
- che si potrebbe verificare con i \textit{thread}
- fra l'apertura del file e l'impostazione della
- suddetta modalità con \func{fcntl} (vedi
- sez.~\ref{sec:file_fcntl_ioctl}).\\
- \const{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
+ \textit{race condition} che si potrebbe verificare
+ con i \textit{thread} fra l'apertura del file e
+ l'impostazione della suddetta modalità con
+ \func{fcntl} (vedi
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
+ \constd{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
\textit{user space} in maniera sincrona, in modo da
scavalcare i meccanismi di bufferizzazione del
kernel. Introdotto con il kernel 2.4.10 ed
utilizzabile soltanto se si è definita la
macro \macro{\_GNU\_SOURCE}.\\
- \const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
+ \constd{O\_NOATIME}& Blocca l'aggiornamento dei tempi di accesso dei
file (vedi sez.~\ref{sec:file_file_times}). Per
molti filesystem questa funzionalità non è
disponibile per il singolo file ma come opzione
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
+ \constd{O\_NONBLOCK}&Apre il file in \textsl{modalità non bloccante} per
le operazioni di I/O (vedi
sez.~\ref{sec:file_noblocking}). Questo significa
il fallimento delle successive operazioni di
blocco delle stesse in attesa di una successiva
possibilità di esecuzione come avviene
normalmente. Questa modalità ha senso solo per le
- fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
+ \textit{fifo}, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
si vuole aprire un file di dispositivo per eseguire
una \func{ioctl} (vedi
sez.~\ref{sec:file_fcntl_ioctl}).\\
- \const{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
+ \constd{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un
errore, questo introduce un'ambiguità, dato che
come vedremo in sez.~\ref{sec:file_read} il ritorno
di un valore nullo da parte di \func{read} ha
il significato di una \textit{end-of-file}.\\
- \const{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
+ \constd{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
scrittura si bloccherà fino alla conferma
dell'arrivo di tutti i dati e di tutti i metadati
sull'hardware sottostante (in questo significato
solo dal kernel 2.6.33).\\
- \const{O\_DSYNC} & Apre il file per l'input/output sincrono. Ogni
+ \constd{O\_DSYNC} & Apre il file per l'input/output sincrono. Ogni
scrittura di dati si bloccherà fino alla conferma
dell'arrivo degli stessi e della parte di metadati
ad essi relativa sull'hardware sottostante (in
sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
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
+anche con la costante \constd{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
\end{funcproto}
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
+eventuale blocco (il \textit{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_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.
+tutte le risorse nella \textit{file table} vengono rilasciate. Infine se il
+file descriptor era l'ultimo riferimento ad un file su disco quest'ultimo
+viene cancellato.
Si ricordi che quando un processo termina tutti i suoi file descriptor vengono
automaticamente chiusi, molti programmi sfruttano questa caratteristica e non
operazioni di lettura e scrittura avvengono a partire da questa posizione che
viene automaticamente spostata in avanti del numero di byte letti o scritti.
-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 di sistema \funcd{lseek}, il cui prototipo è:
+In genere, a meno di non avere richiesto la modalità di scrittura in
+\textit{append} (vedi sez.~\ref{sec:file_write}) con \const{O\_APPEND}, questa
+posizione viene impostata a zero all'apertura del file. È possibile impostarla
+ad un valore qualsiasi con la funzione di sistema \funcd{lseek}, il cui
+prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
{La funzione ritorna il valore della posizione sul file in caso di successo e
$-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
\item[\errcode{EINVAL}] \param{whence} non è un valore valido.
\item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
tipo \type{off\_t}.
+ \item[\errcode{ESPIPE}] \param{fd} è una \textit{pipe}, un socket o una
+ \textit{fifo}.
\end{errlist}
ed inoltre \errval{EBADF} nel suo significato generico.}
\end{funcproto}
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
+ rispettivamente con 0, 1 e 2 o con \constd{L\_SET}, \constd{L\_INCR} e
+ \constd{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
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \const{SEEK\_SET} & Si fa riferimento all'inizio del file: il valore, che
+ \constd{SEEK\_SET}& Si fa riferimento all'inizio del file: il valore, che
deve essere positivo, di \param{offset} indica
direttamente la nuova posizione corrente.\\
- \const{SEEK\_CUR} & Si fa riferimento alla posizione corrente del file:
+ \constd{SEEK\_CUR}& Si fa riferimento alla posizione corrente del file:
ad essa viene sommato \param{offset}, che può essere
negativo e positivo, per ottenere la nuova posizione
corrente.\\
- \const{SEEK\_END} & Si fa riferimento alla fine del file: alle dimensioni
+ \constd{SEEK\_END}& Si fa riferimento alla fine del file: alle dimensioni
del file viene sommato \param{offset}, che può essere
negativo e positivo, per ottenere la nuova posizione
corrente.\\
\hline
- \const{SEEK\_DATA}& Sposta la posizione nel file sull'inizio del primo
+ \constd{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}
(dal kernel 3.1).\\
- \const{SEEK\_HOLE}& Sposta la posizione sul file all'inizio del primo
+ \constd{SEEK\_HOLE}&Sposta la posizione sul file all'inizio del primo
\textit{hole} nel file che segue o inizia
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}
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_shared_access}).
+(questa è una potenziale sorgente di \textit{race 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
non supportano questa funzione, come ad esempio per i file di
terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni
-\index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
-un errore ma restituiscono un valore indefinito.
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
+indefinito.
\itindbeg{sparse~file}
+\index{file!\textit{hole}|(}
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, 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.
+``\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 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}
+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
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 \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}.
+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}.
Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
la dimensione di un file sarà più o meno corrispondente alla quantità di
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
+riconoscere la presenza di \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 \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
+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
disco di un file, per il quale esiste una specifica operazione di controllo
(vedi sez.~\ref{sec:file_fcntl_ioctl}).
+\index{file!\textit{hole}|)}
\subsection{Le funzioni per la lettura di un file}
Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
un numero di byte letti inferiore a quello richiesto, ma questo non è vero
-quando si legge da un terminale, da una fifo o da una pipe. In tal caso
-infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
-non aver selezionato la modalità non bloccante, vedi
-sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
-di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
-con un numero di byte inferiore a quelli richiesti.
+quando si legge da un terminale, da una \textit{fifo} o da una
+\textit{pipe}. In tal caso infatti, se non ci sono dati in ingresso, la
+\func{read} si blocca (a meno di non aver selezionato la modalità non
+bloccante, vedi sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne
+arrivano; se il numero di byte richiesti eccede quelli disponibili la funzione
+ritorna comunque, ma con un numero di byte inferiore a quelli richiesti.
Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
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{EPIPE}] \param{fd} è connesso ad una \textit{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.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EFAULT}, \errval{EIO}, \errval{EISDIR},
\errval{ENOSPC} nel loro significato generico.}
\end{funcproto}
+\itindbeg{append~mode}
+
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
posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+modalità \textit{append} con \const{O\_APPEND} i dati vengono sempre scritti
alla fine del file. Lo standard POSIX richiede che i dati scritti siano
immediatamente disponibili ad una \func{read} chiamata dopo che la
\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
non è detto che tutti i filesystem supportino questa capacità.
+\itindend{append~mode}
+
Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
Per i file ordinari il numero di byte scritti è sempre uguale a quello
indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
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} \textit{inode} su disco.
+nella \textit{file table} faranno però riferimento allo stesso \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
-vengono mantenute nella sua voce della \itindex{file~table} \textit{file
- table}. Questo ha conseguenze specifiche sugli effetti della possibile
-azione simultanea sullo stesso file, in particolare occorre tenere presente
-che:
+vengono mantenute nella sua voce della \textit{file table}. Questo ha
+conseguenze specifiche sugli effetti della possibile 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
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 dalla struttura
- \kstruct{inode}. Dopo la scrittura il file viene automaticamente esteso.
+\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
+ effettuata una scrittura la posizione corrente viene 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 dalla struttura \kstruct{inode}.
+ \var{f\_pos} nella struttura \kstruct{file} della \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
+ dalla struttura \kstruct{inode}.
\end{itemize}
\begin{figure}[!htb]
\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
-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 della relativa tabella dei file aperti.
+puntino alla stessa voce nella \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 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_ioctl}) 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}.
+file descriptor 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 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 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_ioctl}) si applicherebbe a tutti processi che
+condividono la voce nella \textit{file table}. Ai file però sono associati
+anche altri flag, dei quali l'unico usato al momento è \constd{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 \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
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}.
+meccanismi di sincronizzazione espliciti come il \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}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.
+fine del file e poi scrivere può condurre ad una \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 primo processo, avrà una 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.
+risolto introducendo la modalità di scrittura 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}
\end{figure}
Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
-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.
+duplicati condivideranno eventuali lock (vedi sez.~\ref{sec:file_locking}), 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_ioctl}), questo verrà cancellato nel file descriptor
-restituito come copia.
+descriptor, se questo ha il flag di \textit{close-on-exec} attivo (vedi
+sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl}), 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).
+\textit{pipe}) allo \textit{standard input} o allo \textit{standard output}
+(vedremo un esempio in sez.~\ref{sec:ipc_pipe_use}, quando tratteremo le
+\textit{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
+una \textit{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
\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{EBUSY}] si è rilevata la possibilità di una \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.
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.
+atomica e consente di evitare una \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.
+possibilità di una \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_ioctl}) 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}. 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.
+sez.~\ref{sec:file_fcntl_ioctl}) 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}. 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
\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}.
+flag di \textit{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}
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
+\sysctlfiled{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
{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.
+ \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ sincronizzazione.
\end{errlist}
- ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO} nel loro
+ ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
significato generico.}
\end{funcproto}
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.
+gli altri dati contenuti 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 tempi 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 la scrittura della
\itindbeg{at-functions}
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 ad un file posto
-direttamente nella \index{directory~di~lavoro} directory di lavoro corrente,
+come per le altre funzioni che prendono come argomenti dei \textit{pathname}
+relativi, è la possibilità, quando un \textit{pathname} relativo non fa
+riferimento ad un file posto direttamente nella directory di lavoro corrente,
che alcuni dei componenti del \textit{pathname} 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}).
+di una \textit{race condition} in cui c'è spazio per un \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
-lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
-ma esistono molti casi in cui sarebbe invece utile che ogni singolo
-\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
-directory di lavoro.
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+del singolo processo; questo significa che quando si lavora con i
+\textit{thread} essa sarà la stessa per tutti, ma esistono molti casi in cui
+sarebbe invece utile che ogni singolo \textit{thread} avesse la sua directory
+di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
\func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
funzioni, dette anche ``\textit{at-functions}'' in quanto contraddistinte dal
suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
-altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
-relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
- proposta dello sviluppatore principale della \acr{glibc} Urlich Drepper e le
- corrispondenti \textit{system call} sono state inserite nel kernel a partire
- dalla versione 2.6.16, in precedenza era disponibile una emulazione che, sia
- pure con prestazioni inferiori, funzionava facendo ricorso all'uso del
- filesystem \textit{proc} con l'apertura del file attraverso il riferimento a
+altre operazioni) usando un \textit{pathname} relativo ad una directory
+specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
+ principale della \acr{glibc} Urlich Drepper e le corrispondenti
+ \textit{system call} sono state inserite nel kernel a partire dalla versione
+ 2.6.16, in precedenza era disponibile una emulazione che, sia pure con
+ prestazioni inferiori, funzionava facendo ricorso all'uso del filesystem
+ \textit{proc} con l'apertura del file attraverso il riferimento a
\textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
Benché queste funzioni non siano presenti negli standard tradizionali esse
-sono state adottate da altri sistemi unix-like com Solaris i vari BSD, fino ad
-essere incluse in una recente revisione (la POSIX.1-2008) dello standard
+sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino
+ad essere incluse in una recente revisione (la POSIX.1-2008) dello standard
POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
definire la macro \macro{\_ATFILE\_SOURCE}.
L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei \itindsub{pathname}{relativo}
-\textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
-passare il relativo file descriptor alle varie funzioni che useranno quella
-directory come punto di partenza per la risoluzione. In questo modo, anche
-quando si lavora con i \itindex{thread} \textit{thread}, si può mantenere una
-\index{directory~di~lavoro} directory di lavoro diversa per ciascuno di essi.
-
-Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
-\textit{race condition}, consente anche di ottenere aumenti di prestazioni
-significativi quando si devono eseguire molte operazioni su sezioni
-dell'albero dei file che prevedono delle gerarchie di sottodirectory molto
-profonde. Infatti in questo caso basta eseguire la risoluzione del
-\textit{pathname} della directory di partenza una sola volta (nell'apertura
-iniziale) e non tutte le volte che si deve accedere a ciascun file che essa
-contiene.
+sarà la base della risoluzione dei \textit{pathname} relativi che verranno
+usati in seguito, dopo di che si dovrà passare il relativo file descriptor
+alle varie funzioni che useranno quella directory come punto di partenza per
+la risoluzione. In questo modo, anche quando si lavora con i \textit{thread},
+si può mantenere una directory di lavoro diversa per ciascuno di essi.
+
+Questo metodo, oltre a risolvere i problemi di \textit{race condition},
+consente anche di ottenere aumenti di prestazioni significativi quando si
+devono eseguire molte operazioni su sezioni dell'albero dei file che prevedono
+delle gerarchie di sottodirectory molto profonde. Infatti in questo caso basta
+eseguire la risoluzione del \textit{pathname} della directory di partenza una
+sola volta (nell'apertura iniziale) e non tutte le volte che si deve accedere
+a ciascun file che essa contiene.
La sintassi generale di queste nuove funzioni è che esse prevedono come primo
argomento il file descriptor della directory da usare come base per la
\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.}
+\fdesc{Apre un file a partire da una directory di 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.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \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
-argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
-relativo questo sarà risolto rispetto alla directory indicata
-da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
+argomenti si utilizza un \textit{pathname} relativo questo sarà risolto
+rispetto alla directory indicata da \param{dirfd}. Qualora invece si usi un
\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
-se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
-risoluzione sarà effettuata rispetto alla directory di
-\index{directory~di~lavoro} lavoro corrente del processo. Si tenga presente
-però che 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.
+se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD}, la
+risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
+processo. Si tenga presente però che 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.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
particolare si avrà un errore di \errcode{EBADF} se esso non è un file
descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
riferimento ad una directory, tranne il caso in cui si sia specificato un
-\itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel qual caso, come
-detto, il valore di \param{dirfd} sarà completamente ignorato.
+\textit{pathname} assoluto, nel qual caso, come detto, il valore
+di \param{dirfd} sarà completamente ignorato.
\begin{table}[htb]
\centering
% TODO manca prototipo di linkat, verificare se metterlo o metter menzione
+% altre modifiche al riguardo nel 3.11 (AT_EMPTY_PATH?) vedi
+% http://lwn.net/Articles/562488/
% TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
+% TODO manca prototipo di renameat2, introdotta nel 3.15, vedi
+% http://lwn.net/Articles/569134/
+% TODO manca prototipo di execveat, introdotta nel 3.19, vedi
+% https://lwn.net/Articles/626150/ cerca anche fexecve
+
Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
\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.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
\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.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
La seconda eccezione è \funcd{unlinkat}, in questo caso
l'argomento \param{flags} viene utilizzato perché tramite esso si può indicare
-alla fuzione di comportarsi sia come analogo di \func{unlink} che di
+alla funzione di comportarsi sia come analogo di \func{unlink} che di
\func{rmdir}; il suo prototipo è:
\begin{funcproto}{
\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.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un \textit{pathname} relativo,
+ ma \param{dirfd} fa riferimento ad un file.
\end{errlist}
}
\end{funcproto}
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \const{AT\_SYMLINK\_NOFOLLOW}& se impostato la funzione non esegue la
- dereferenziazione dei collegamenti simbolici.\\
- \const{AT\_SYMLINK\_FOLLOW}& se impostato la funzione esegue la
- dereferenziazione dei collegamenti simbolici
- (usato esplicitamente solo da \func{linkat}).\\
- \const{AT\_EACCES} & usato solo da \func{faccessat}, richiede che
- il controllo dei permessi sia fatto usando
- l'\ids{UID} effettivo invece di quello
- reale.\\
- \const{AT\_REMOVEDIR} & usato solo da \func{unlinkat}, richiede che
- la funzione si comporti come \func{rmdir}
- invece che come \func{unlink}.\\
+ \constd{AT\_SYMLINK\_NOFOLLOW}& Se impostato la funzione non esegue la
+ dereferenziazione dei collegamenti
+ simbolici.\\
+ \constd{AT\_SYMLINK\_FOLLOW}& Se impostato la funzione esegue la
+ dereferenziazione dei collegamenti simbolici
+ (usato esplicitamente solo da
+ \func{linkat}).\\
+ \constd{AT\_EACCES} & Usato solo da \func{faccessat}, richiede che
+ il controllo dei permessi sia fatto usando
+ l'\ids{UID} effettivo invece di quello
+ reale.\\
+ \constd{AT\_REMOVEDIR} & Usato solo da \func{unlinkat}, richiede che
+ la funzione si comporti come \func{rmdir}
+ invece che come \func{unlink}.\\
\hline
\end{tabular}
\caption{Le costanti utilizzate per i bit dell'argomento
Un'ultima differenza fra le \textit{at-functions} e le funzioni tradizionali
di cui sono estensione è, come accennato in sez.~\ref{sec:file_temp_file},
-quella relativa a \funcm{utimensat} che non è propriamente una corrispondente
+quella relativa a \func{utimensat} che non è propriamente una corrispondente
esatta di \func{utimes} e \func{lutimes}, dato che questa funzione ha una
maggiore precisione nella indicazione dei tempi dei file, per i quali come per
\func{futimes}, si devono usare strutture \struct{timespec} che consentono una
% inserita nello stesso standard e da usare con openat, vedi
% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
+% TODO: manca prototipo e motivazione di execveat, vedi
+% http://man7.org/linux/man-pages/man2/execveat.2.html
\subsection{Le operazioni di controllo}
\label{sec:file_fcntl_ioctl}
caratteristiche di un file descriptor, viene usata la funzione di sistema
\funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
modalità di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_operation}) e
- il \itindex{file~locking} \textit{file locking} (vedi
- sez.~\ref{sec:file_locking}).} il cui prototipo è:
+ il \textit{file locking} (vedi sez.~\ref{sec:file_locking}).} il cui
+prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
possibili valori per \var{cmd}, e del relativo significato, dei codici di
errore restituiti e del tipo del terzo argomento (cui faremo riferimento con
il nome indicato nel precedente prototipo), è riportata di seguito:
-\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
+\begin{basedescript}{\desclabelwidth{1.8cm}}
+\item[\constd{F\_DUPFD}] trova il primo file descriptor disponibile di valore
maggiore o uguale ad \param{arg}, e ne fa un duplicato
di \param{fd}, ritorna il nuovo file descriptor in caso di successo e $-1$
in caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
o \errcode{EMFILE} se il processo ha già raggiunto il massimo numero di
descrittori consentito.
-\item[\const{F\_DUPFD\_CLOEXEC}] ha lo stesso effetto di \const{F\_DUPFD}, ma
- in più attiva il flag di \itindex{close-on-exec} \textit{close-on-exec} sul
- file descriptor duplicato, in modo da evitare una successiva chiamata con
+\itindbeg{close-on-exec}
+
+\item[\constd{F\_DUPFD\_CLOEXEC}] ha lo stesso effetto di \const{F\_DUPFD}, ma
+ in più attiva il flag di \textit{close-on-exec} sul file descriptor
+ duplicato, in modo da evitare una successiva chiamata con
\const{F\_SETFD}. La funzionalità è stata introdotta con il kernel 2.6.24 ed
è prevista nello standard POSIX.1-2008 (si deve perciò definire
\macro{\_POSIX\_C\_SOURCE} ad un valore adeguato secondo quanto visto in
sez.~\ref{sec:intro_gcc_glibc_std}).
-\item[\const{F\_GETFD}] ritorna il valore dei \textit{file descriptor flags} di
- \param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
- viene ignorato. Non sono previsti errori diversi da \errval{EBADF}. Al
- momento l'unico flag usato è quello di \itindex{close-on-exec}
+\item[\constd{F\_GETFD}] restituisce il valore dei \textit{file descriptor
+ flags} di \param{fd} in caso di successo o $-1$ in caso di errore, il
+ terzo argomento viene ignorato. Non sono previsti errori diversi da
+ \errval{EBADF}. Al momento l'unico flag usato è quello di
\textit{close-on-exec}, identificato dalla costante \const{FD\_CLOEXEC}, che
serve a richiedere che il file venga chiuso nella esecuzione di una
\func{exec} (vedi sez.~\ref{sec:proc_exec}). Un valore nullo significa
pertanto che il flag non è impostato.
-\item[\const{F\_SETFD}] imposta il valore dei \textit{file descriptor flags}
+\item[\constd{F\_SETFD}] imposta il valore dei \textit{file descriptor flags}
al valore specificato con \param{arg}, ritorna un valore nullo in caso di
successo e $-1$ in caso di errore. Non sono previsti errori diversi da
\errval{EBADF}. Dato che l'unico flag attualmente usato è quello di
- \itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
- \const{FD\_CLOEXEC}, tutti gli altri bit di \param{arg}, anche se impostati,
- vengono ignorati.\footnote{questo almeno è quanto avviene fino al kernel
- 3.2, come si può evincere dal codice della funzione \texttt{do\_fcntl} nel
- file \texttt{fs/fcntl.c} dei sorgenti del kernel.}
-
-\item[\const{F\_GETFL}] ritorna il valore dei \textit{file status flags} di
+ \textit{close-on-exec}, identificato dalla costante \const{FD\_CLOEXEC},
+ tutti gli altri bit di \param{arg}, anche se impostati, vengono
+ ignorati.\footnote{questo almeno è quanto avviene fino al kernel 3.2, come
+ si può evincere dal codice della funzione \texttt{do\_fcntl} nel file
+ \texttt{fs/fcntl.c} dei sorgenti del kernel.}
+\itindend{close-on-exec}
+
+\item[\constd{F\_GETFL}] ritorna il valore dei \textit{file status flags} di
\param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
viene ignorato. Non sono previsti errori diversi da \errval{EBADF}. Il
comando permette di rileggere il valore di quei bit
dell'argomento \param{flags} di \func{open} che vengono memorizzati nella
relativa voce della \textit{file table} all'apertura del file, vale a dire
quelli riportati in tab.~\ref{tab:open_access_mode_flag} e
- tab.~\ref{tab:open_operation_flag}).
+ tab.~\ref{tab:open_operation_flag}). Si ricordi che quando si usa la
+ funzione per determinare le modalità di accesso con cui è stato aperto il
+ file è necessario estrarre i bit corrispondenti nel \textit{file status
+ flag} con la maschera \const{O\_ACCMODE} come già accennato in
+ sez.~\ref{sec:file_open_close}.
-\item[\const{F\_SETFL}] imposta il valore dei \textit{file status flags} al
+\item[\constd{F\_SETFL}] imposta il valore dei \textit{file status flags} al
valore specificato da \param{arg}, ritorna un valore nullo in caso di
successo o $-1$ in caso di errore. In generale possono essere impostati solo
i flag riportati in tab.~\ref{tab:open_operation_flag}, su Linux si possono
\errcode{EPERM} se si cerca di rimuovere \const{O\_APPEND} da un file
marcato come \textit{append-only} o se di cerca di impostare
\const{O\_NOATIME} su un file di cui non si è proprietari (e non si hanno i
- permessi di amministatore) ed \errcode{EINVAL} se si cerca di impostare
+ permessi di amministratore) ed \errcode{EINVAL} se si cerca di impostare
\const{O\_DIRECT} su un file che non supporta questo tipo di operazioni.
-\item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
+\item[\constd{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. Come
per i due successivi comandi oltre a \errval{EBADF} se \param{lock} non è un
puntatore valido restituisce l'errore generico \errcode{EFAULT}. Questa
funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
+\item[\constd{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
specificato nella struttura puntata da \param{lock}, ritorna un valore nullo
in caso di successo e $-1$ se il file lock è tenuto da qualcun altro, nel
qual caso si ha un errore di \errcode{EACCES} o \errcode{EAGAIN}. Questa
funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
+\item[\constd{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
la funzione non ritorna subito ma attende che il blocco sia rilasciato, se
l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
imposta \var{errno} a \errcode{EINTR}. Questa funzionalità è trattata in
dettaglio in sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_GETOWN}] restituisce in caso di successo l'identificatore del
- processo o del \itindex{process~group} \textit{process group} (vedi
- sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione del segnale
- \signal{SIGIO} (o l'eventuale segnale alternativo impostato con
- \const{F\_SETSIG}) per gli eventi asincroni associati al file
- descriptor \param{fd} e del segnale \signal{SIGURG} per la notifica dei dati
- urgenti di un socket (vedi sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$
- in caso di errore ed il terzo argomento viene ignorato. Non sono previsti
- errori diversi da \errval{EBADF}.
+\item[\constd{F\_GETOWN}] restituisce in caso di successo l'identificatore del
+ processo o del \textit{process group} (vedi sez.~\ref{sec:sess_proc_group})
+ che è preposto alla ricezione del segnale \signal{SIGIO} (o l'eventuale
+ segnale alternativo impostato con \const{F\_SETSIG}) per gli eventi
+ asincroni associati al file descriptor \param{fd} e del segnale
+ \signal{SIGURG} per la notifica dei dati urgenti di un socket (vedi
+ sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$ in caso di errore ed il
+ terzo argomento viene ignorato. Non sono previsti errori diversi da
+ \errval{EBADF}.
Per distinguerlo dal caso in cui il segnale viene inviato a un singolo
processo, nel caso di un \textit{process group} viene restituito un valore
negativo il cui valore assoluto corrisponde all'identificatore del
- \itindex{process~group} \textit{process group}. Con Linux questo comporta un
- problema perché se il valore restitituito dalla \textit{system call} è
- compreso nell'intervallo fra $-1$ e $-4095$ in alcune architetture questo
- viene trattato dalla \acr{glibc} come un errore,\footnote{il problema deriva
- dalle limitazioni presenti in architetture come quella dei normali PC
- (i386) per via delle modalità in cui viene effettuata l'invocazione delle
- \textit{system call} che non consentono di restituire un adeguato codice
- di ritorno.} per cui in tal caso \func{fcntl} ritornerà comunque $-1$
- mentre il valore restituito dalla \textit{system call} verrà assegnato ad
- \var{errno}, cambiato di segno.
+ \textit{process group}. Con Linux questo comporta un problema perché se il
+ valore restituito dalla \textit{system call} è compreso nell'intervallo fra
+ $-1$ e $-4095$ in alcune architetture questo viene trattato dalla
+ \acr{glibc} come un errore,\footnote{il problema deriva dalle limitazioni
+ presenti in architetture come quella dei normali PC (i386) per via delle
+ modalità in cui viene effettuata l'invocazione delle \textit{system call}
+ che non consentono di restituire un adeguato codice di ritorno.} per cui
+ in tal caso \func{fcntl} ritornerà comunque $-1$ mentre il valore restituito
+ dalla \textit{system call} verrà assegnato ad \var{errno}, cambiato di
+ segno.
Per questo motivo con il kernel 2.6.32 è stato introdotto il comando
alternativo \const{F\_GETOWN\_EX}, che vedremo a breve, che consente di
disponibile, usa questa versione alternativa per mascherare il problema
precedente e restituire un valore corretto in tutti i casi.\footnote{in cui
cioè viene restituito un valore negativo corretto qualunque sia
- l'identificatore del \itindex{process~group} \textit{process group}, che
- non potendo avere valore unitario (non esiste infatti un
- \itindex{process~group} \textit{process group} per \cmd{init}) non può
- generare ambiguità con il codice di errore.} Questo però comporta che il
- comportamento del comando può risultare diverso a seconda delle versioni
+ l'identificatore del \textit{process group}, che non potendo avere valore
+ unitario (non esiste infatti un \textit{process group} per \cmd{init}) non
+ può generare ambiguità con il codice di errore.} Questo però comporta che
+ il comportamento del comando può risultare diverso a seconda delle versioni
della \acr{glibc} e del kernel.
-\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
- l'identificatore del processo o del \itindex{process~group} \textit{process
- group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
- eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
- caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} gli errori
- possibili sono \errcode{ESRCH} se \param{arg} indica un processo o un
- \itindex{process~group} \textit{process group} inesistente.
+\item[\constd{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
+ l'identificatore del processo o del \textit{process group} che riceverà i
+ segnali \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{ESRCH} se \param{arg} indica un processo o un \textit{process
+ group} inesistente.
L'impostazione è soggetta alle stesse restrizioni presenti sulla funzione
\func{kill} (vedi sez.~\ref{sec:sig_kill_raise}), per cui un utente non
privilegiato può inviare i segnali solo ad un processo che gli appartiene,
in genere comunque si usa il processo corrente. Come per \const{F\_GETOWN},
- per indicare un \itindex{process~group} \textit{process group} si deve usare
- per \param{arg} un valore negativo, il cui valore assoluto corrisponda
- all'identificatore del \itindex{process~group} \textit{process group}.
+ per indicare un \textit{process group} si deve usare per \param{arg} un
+ valore negativo, il cui valore assoluto corrisponda all'identificatore del
+ \textit{process group}.
A partire dal kernel 2.6.12 se si sta operando con i \textit{thread} della
implementazione nativa di Linux (quella della NTPL, vedi
caso è anche l'unico, mantiene un valore del \textit{Thread ID} uguale al
\ids{PID} del processo. Il problema è però che questo comportamento non si
applica a \signal{SIGURG}, per il quale \param{arg} viene sempre
- interpretato come l'identificatore di un processo o di un
- \itindex{process~group} \textit{process group}.
-
-\item[\const{F\_GETOWN\_EX}] legge nella struttura puntata
- dal'argomento \param{owner} l'identificatore del processo, \textit{thread} o
- \itindex{process~group} \textit{process group} (vedi
- sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione dei segnali
- \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
- descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$
- in caso di errore. Oltre a \errval{EBADF} e da
- \errval{EFAULT} se \param{owner} non è un puntatore valido.
+ interpretato come l'identificatore di un processo o di un \textit{process
+ group}.
+
+\item[\constd{F\_GETOWN\_EX}] legge nella struttura puntata
+ dall'argomento \param{owner} l'identificatore del processo, \textit{thread}
+ o \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) che è
+ preposto alla ricezione dei segnali \signal{SIGIO} e \signal{SIGURG} per gli
+ eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
+ caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} e da
+ \errval{EFAULT} se \param{owner} non è un puntatore valido.
Il comando, che è disponibile solo a partire dal kernel 2.6.32, effettua lo
stesso compito di \const{F\_GETOWN} di cui costituisce una evoluzione che
di \const{F\_GETOWN}. Il comando è specifico di Linux ed utilizzabile solo
se si è definita la macro \macro{\_GNU\_SOURCE}.
-\item[\const{F\_SETOWN\_EX}] imposta con il valore della struttura
+\item[\constd{F\_SETOWN\_EX}] imposta con il valore della struttura
\struct{f\_owner\_ex} puntata \param{owner}, l'identificatore del processo o
- del \itindex{process~group} \textit{process group} che riceverà i segnali
- \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ del \textit{process group} che riceverà i segnali \signal{SIGIO} e
+ \signal{SIGURG} per gli eventi associati al file
descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
caso di errore, con gli stessi errori di \const{F\_SETOWN} più
\errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
Come \const{F\_GETOWN\_EX} il comando richiede come terzo argomento il
puntatore ad una struttura \struct{f\_owner\_ex} la cui definizione è
riportata in fig.~\ref{fig:f_owner_ex}, in cui il primo campo indica il tipo
- di indentificatore il cui valore è specificato nel secondo campo, che assume
+ di identificatore il cui valore è specificato nel secondo campo, che assume
lo stesso significato di \param{arg} per \const{F\_SETOWN}. Per il campo
- \var{type} i soli valori validi sono \const{F\_OWNER\_TID},
- \const{F\_OWNER\_PID} e \const{F\_OWNER\_PGRP}, che indicano rispettivamente
- che si intedende specificare con \var{pid} un \textit{Tread ID}, un
- \textit{Process ID} o un \textit{Process Group ID}. A differenza di
- \const{F\_SETOWN} se si specifica un \textit{Tread ID} questo riceverà sia
- \signal{SIGIO} (o il segnale impostato con \const{F\_SETSIG}) che
+ \var{type} i soli valori validi sono \constd{F\_OWNER\_TID},
+ \constd{F\_OWNER\_PID} e \constd{F\_OWNER\_PGRP}, che indicano
+ rispettivamente che si intende specificare con \var{pid} un \textit{Tread
+ ID}, un \textit{Process ID} o un \textit{Process Group ID}. A differenza
+ di \const{F\_SETOWN} se si specifica un \textit{Tread ID} questo riceverà
+ sia \signal{SIGIO} (o il segnale impostato con \const{F\_SETSIG}) che
\signal{SIGURG}. Il comando è specifico di Linux, è disponibile solo a
partire dal kernel 2.6.32, ed è utilizzabile solo se si è definita la macro
\macro{\_GNU\_SOURCE}.
-\item[\const{F\_GETSIG}] restituisce il valore del segnale inviato dai vari
+\item[\constd{F\_GETSIG}] restituisce il valore del segnale inviato dai vari
meccanismi di I/O asincrono associati al file descriptor \param{fd} (quelli
trattati in sez.~\ref{sec:file_asyncronous_operation}) in caso di successo o
$-1$ in caso di errore, il terzo argomento viene ignorato. Non sono previsti
essere anche lo stesso \signal{SIGIO}. Il comando è specifico di Linux ed
utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
-\item[\const{F\_SETSIG}] imposta il segnale inviato dai vari meccanismi di I/O
- asincrono associati al file descriptor \param{fd} (quelli trattati in
+\item[\constd{F\_SETSIG}] imposta il segnale inviato dai vari meccanismi di
+ I/O asincrono associati al file descriptor \param{fd} (quelli trattati in
sez.~\ref{sec:file_asyncronous_operation}) al valore indicato
da \param{arg}, ritorna un valore nullo in caso di successo o $-1$ in caso
di errore. Oltre a \errval{EBADF} gli errori possibili sono
sez.~\ref{sec:sig_real_time}), ed in particolare la capacità di essere
accumulati in una coda prima della notifica.
-\item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
- \textit{file lease} che il processo detiene nei confronti del file
- descriptor \var{fd} o $-1$ in caso di errore, il terzo argomento viene
- ignorato. Non sono previsti errori diversi da \errval{EBADF}. Il comando è
- specifico di Linux ed utilizzabile solo se si è definita la macro
- \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in dettaglio in
- sez.~\ref{sec:file_asyncronous_lease}.
-
-\item[\const{F\_SETLEASE}] imposta o rimuove a seconda del valore
- di \param{arg} un \itindex{file~lease} \textit{file lease} sul file
- descriptor \var{fd} a seconda del valore indicato da \param{arg}. Ritorna un
- valore nullo in caso di successo o $-1$ in caso di errore. Oltre a
- \errval{EBADF} si otterrà \errcode{EINVAL} se si è specificato un valore non
- valido per \param{arg} (deve essere usato uno dei valori di
- tab.~\ref{tab:file_lease_fctnl}), \errcode{ENOMEM} se non c'è memoria
- sufficiente per creare il \textit{file lease}, \errcode{EACCESS} se non si è
- il proprietario del file e non si hanno i privilegi di
- amministratore.\footnote{per la precisione occorre la capacità
- \itindex{capabilities} \const{CAP\_LEASE}.}
-
- Il comando è specifico di Linux ed utilizzabile solo se si è definita la
- macro \macro{\_GNU\_SOURCE}. Il comando è presente a partire dai kernel
- della serie 2.4.x, quando è stato introdotto il supporto \textit{file
- lease}, per cui un processo che detiene un \textit{lease} su un file
- riceve una notifica qualora un altro processo cerchi di eseguire una
- \func{open} o una \func{truncate} su di esso. Questa funzionalità è trattata
- in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
-
-\item[\const{F\_NOTIFY}] attiva il meccanismo di notifica asincrona per cui
+\item[\constd{F\_GETLEASE}] restituisce il tipo di \textit{file lease} che il
+ processo detiene nei confronti del file descriptor \var{fd} o $-1$ in caso
+ di errore, il terzo argomento viene ignorato. Non sono previsti errori
+ diversi da \errval{EBADF}. Il comando è specifico di Linux ed utilizzabile
+ solo se si è definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è
+ trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\constd{F\_SETLEASE}] imposta o rimuove a seconda del valore
+ di \param{arg} un \textit{file lease} sul file descriptor \var{fd} a seconda
+ del valore indicato da \param{arg}. Ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. Oltre a \errval{EBADF} si otterrà
+ \errcode{EINVAL} se si è specificato un valore non valido per \param{arg}
+ (deve essere usato uno dei valori di tab.~\ref{tab:file_lease_fctnl}),
+ \errcode{ENOMEM} se non c'è memoria sufficiente per creare il \textit{file
+ lease}, \errcode{EACCES} se non si è il proprietario del file e non si
+ hanno i privilegi di amministratore.\footnote{per la precisione occorre la
+ capacità \const{CAP\_LEASE}.}
+
+ Il supporto il supporto per i \textit{file lease}, che consente ad un
+ processo che detiene un \textit{lease} su un file di riceve una notifica
+ qualora un altro processo cerchi di eseguire una \func{open} o una
+ \func{truncate} su di esso è stato introdotto a partire dai kernel della
+ serie 2.4 Il comando è specifico di Linux ed utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\constd{F\_NOTIFY}] attiva il meccanismo di notifica asincrona per cui
viene riportato al processo chiamante, tramite il segnale \signal{SIGIO} (o
altro segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
dai kernel della serie 2.4.x, è trattata in dettaglio in
sez.~\ref{sec:file_asyncronous_lease}.
-\item[\const{F\_GETPIPE\_SZ}]
+\item[\constd{F\_GETPIPE\_SZ}] restituisce in caso di successo la dimensione
+ del buffer associato alla \textit{pipe} \param{fd} (vedi
+ sez.~\ref{sec:ipc_pipes}) o $-1$ in caso di errore, il terzo argomento viene
+ ignorato. Non sono previsti errori diversi da \errval{EBADF}, che viene
+ restituito anche se il file descriptor non è una \textit{pipe}. Il comando è
+ specifico di Linux, è disponibile solo a partire dal kernel 2.6.35, ed è
+ utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
-\item[\const{F\_SETPIPE\_SZ}]
+\item[\constd{F\_SETPIPE\_SZ}] imposta la dimensione del buffer associato alla
+ \textit{pipe} \param{fd} (vedi sez.~\ref{sec:ipc_unix}) ad un valore uguale
+ o superiore a quello indicato dall'argomento \param{arg}. Ritorna un valore
+ nullo in caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF}
+ gli errori possibili sono \errcode{EBUSY} se si cerca di ridurre la
+ dimensione del buffer al di sotto della quantità di dati effettivamente
+ presenti su di esso ed \errcode{EPERM} se un processo non privilegiato cerca
+ di impostare un valore troppo alto. La dimensione minima del buffer è pari
+ ad una pagina di memoria, a cui verrà comunque arrotondata ogni dimensione
+ inferiore, il valore specificato viene in genere arrotondato per eccesso al
+ valore ritenuto più opportuno dal sistema, pertanto una volta eseguita la
+ modifica è opportuno rileggere la nuova dimensione con
+ \const{F\_GETPIPE\_SZ}. I processi non privilegiati\footnote{per la
+ precisione occorre la capacità \const{CAP\_SYS\_RESOURCE}.} non possono
+ impostare un valore valore superiore a quello indicato da
+ \sysctlfiled{fs/pipe-size-max}. Il comando è specifico di Linux, è
+ disponibile solo a partire dal kernel 2.6.35, ed è utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}.
\end{basedescript}
+% TODO: trattare RWH_WRITE_LIFE_EXTREME e RWH_WRITE_LIFE_SHORT aggiunte con
+% il kernel 4.13 (vedi https://lwn.net/Articles/727385/)
+
La maggior parte delle funzionalità controllate dai comandi di \func{fcntl}
-sono molto avanzate e richiedono degli approfondimenti ulteriori rispetto a
-quanto illustrato adesso; saranno pertanto riprese più avanti quando
-affronteremo le problematiche ad esse relative. In particolare le tematiche
-relative all'I/O asincrono e ai vari meccanismi di notifica saranno trattate
-in maniera esaustiva in sez.~\ref{sec:file_asyncronous_operation} mentre
-quelle relative al \itindex{file~locking} \textit{file locking} saranno
-esaminate in sez.~\ref{sec:file_locking}). L'uso di questa funzione con i
-socket verrà trattato in sez.~\ref{sec:sock_ctrl_func}.
+sono avanzate e richiedono degli approfondimenti ulteriori, saranno pertanto
+riprese più avanti quando affronteremo le problematiche ad esse relative. In
+particolare le tematiche relative all'I/O asincrono e ai vari meccanismi di
+notifica saranno trattate in maniera esaustiva in
+sez.~\ref{sec:file_asyncronous_operation} mentre quelle relative al
+\textit{file locking} saranno esaminate in sez.~\ref{sec:file_locking}). L'uso
+di questa funzione con i socket verrà trattato in
+sez.~\ref{sec:sock_ctrl_func}.
La gran parte dei comandi di \func{fcntl} (\const{F\_DUPFD}, \const{F\_GETFD},
\const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL}, \const{F\_GETLK},
-\const{F\_SETLK} e \const{F\_SETLKW}) sono presenti da molto tempo, sono
-previsti da SVr4 e 4.3BSD e standardizzati in POSIX.1-2001 che inoltre prevede
-gli ulteriori \const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si
-sono indicate esplicitamente soltanto le ulteriori richieste in termini delle
-macro di funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
+\const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4 e 4.3BSD e
+standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
+\const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si sono indicate
+esplicitamente soltanto le ulteriori richieste in termini delle macro di
+funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
funzionalità inserite in standard successivi o specifiche di Linux.
-Si tenga presente infine che quando si usa la funzione per determinare le
-modalità di accesso con cui è stato aperto il file (attraverso l'uso del
-comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
-\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
-di quest'ultimo non assegna bit separati alle tre diverse modalità
-\const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
- queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
-motivo il valore della modalità di accesso corrente si ottiene eseguendo un
-AND binario del valore di ritorno di \func{fcntl} con la maschera
-\const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
-bit di accesso dal \textit{file status flag}.
-
-
% \subsection{La funzione \func{ioctl}}
% \label{sec:file_ioctl}
-Benché il concetto di \textit{everything is a file} si sia dimostrato molto
-valido anche per l'interazione con i dispositivi più vari, fornendo una
-interfaccia che permette di interagire con essi tramite le stesse funzioni
-usate per i normali file di dati, esisteranno sempre caratteristiche
-peculiari, specifiche dell'hardware e della funzionalità che ciascun
-dispositivo può provvedere, che non possono venire comprese in questa
+Benché l'interfaccia di gestione dell'I/O sui file di cui abbiamo parlato
+finora si sia dimostrata valida anche per l'interazione diretta con le
+periferiche attraverso i loro file di dispositivo, consentendo di usare le
+stesse funzioni utilizzate per i normali file di dati, esistono però
+caratteristiche peculiari, specifiche dell'hardware e delle funzionalità che
+ciascun dispositivo può provvedere, che non possono venire comprese in questa
interfaccia astratta come ad esempio l'impostazione della velocità di una
porta seriale, o le dimensioni di un framebuffer.
Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
-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 è:
+di una apposita funzione di sistema, \funcd{ioctl}, come meccanismo generico
+per compiere operazioni specializzate; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/ioctl.h}
sempre $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
+ \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
+ validi.
\item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
riferimento \param{fd}.
- \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
- validi.
\end{errlist}
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
+
+La funzione richiede che si passi come primo argomento un file
+descriptor \param{fd} regolarmente aperto, mentre l'operazione da compiere
+deve essere indicata dal 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.
+generica (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.
Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
-errore, ma per alcune operazione il valore di ritorno, che nel caso viene
-impostato ad un valore positivo, può essere utilizzato come parametro di
-uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
-terzo argomento.
+errore, ma per alcune operazioni il valore di ritorno, che nel caso viene
+impostato ad un valore positivo, può essere utilizzato come indicazione del
+risultato della stessa. È più comune comunque restituire i risultati
+all'indirizzo puntato dal terzo argomento.
Data la genericità dell'interfaccia non è possibile classificare in maniera
sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
\begin{itemize*}
\item il cambiamento dei font di un terminale.
\item l'esecuzione di una traccia audio di un CDROM.
-\item i comandi di avanti veloce e riavvolgimento di un nastro.
+\item i comandi di avanti veloce e di riavvolgimento di un nastro.
\item il comando di espulsione di un dispositivo rimovibile.
\item l'impostazione della velocità trasmissione di una linea seriale.
\item l'impostazione della frequenza e della durata dei suoni emessi dallo
In generale ogni dispositivo ha un suo insieme di operazioni specifiche
effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
-file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
+file \headfiled{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
Data la assoluta specificità della funzione, il cui comportamento varia da
dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
-sommaria delle sue caratteristiche; torneremo ad esaminare in
-seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
- sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
-esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
-quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
-operazioni che sono predefinite per qualunque file,\footnote{in particolare
- queste operazioni sono definite nel kernel a livello generale, e vengono
- sempre interpretate per prime, per cui, come illustrato in \cite{LinDevDri},
- eventuali operazioni specifiche che usino lo stesso valore verrebbero
- ignorate.} caratterizzate dal prefisso \texttt{FIO}:
+sommaria delle sue caratteristiche; torneremo ad esaminare in seguito quelle
+relative ad alcuni casi specifici, ad esempio la gestione dei terminali è
+effettuata attraverso \func{ioctl} in quasi tutte le implementazioni di Unix,
+mentre per l'uso di \func{ioctl} con i socket si veda
+sez.~\ref{sec:sock_ctrl_func}.
+
+Riportiamo qui solo l'elenco delle operazioni che sono predefinite per
+qualunque file, caratterizzate dal prefisso \texttt{FIO}. Queste operazioni
+sono definite nel kernel a livello generale, e vengono sempre interpretate per
+prime, per cui, come illustrato in \cite{LinDevDri}, eventuali operazioni
+specifiche che usino lo stesso valore verrebbero ignorate:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{FIOCLEX}] imposta il flag di \itindex{close-on-exec}
- \textit{close-on-exec} sul file, in questo caso, essendo usata come
- operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
- eventuale valore viene ignorato.
-\item[\const{FIONCLEX}] cancella il flag di \itindex{close-on-exec}
- \textit{close-on-exec} sul file, in questo caso, essendo usata come
- operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
- eventuale valore viene ignorato.
-\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
+\item[\constd{FIOCLEX}] imposta il flag di \textit{close-on-exec} sul file, in
+ questo caso, essendo usata come operazione logica, \func{ioctl} non richiede
+ un terzo argomento, il cui eventuale valore viene ignorato.
+\item[\constd{FIONCLEX}] cancella il flag di \textit{close-on-exec} sul file,
+ in questo caso, essendo usata come operazione logica, \func{ioctl} non
+ richiede un terzo argomento, il cui eventuale valore viene ignorato.
+\item[\constd{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
file (vedi sez.~\ref{sec:signal_driven_io}); il terzo argomento
deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
che contiene un valore logico (un valore nullo disabilita, un valore non
nullo abilita).
-\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
+\item[\constd{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
tipo \texttt{const int *}) che contiene un valore logico (un valore nullo
disabilita, un valore non nullo abilita).
-\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
+\item[\constd{FIOSETOWN}] imposta il processo che riceverà i segnali
\signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
valore specifica il PID del processo.
-\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
+\item[\constd{FIOGETOWN}] legge il processo che riceverà i segnali
\signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
scritto il PID del processo.
-\item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
- file descriptor;\footnote{questa operazione è disponibile solo su alcuni
- file descriptor, in particolare sui socket (vedi
- sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
- (vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
- puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
- il valore.
-\item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
+\item[\constd{FIONREAD}] legge il numero di byte disponibili in lettura sul
+ file descriptor; questa operazione è disponibile solo su alcuni file
+ descriptor, in particolare sui socket (vedi sez.~\ref{sec:sock_ioctl_IP}) o
+ sui file descriptor di \textit{epoll} (vedi sez.~\ref{sec:file_epoll}), il
+ terzo argomento deve essere un puntatore ad un intero (cioè di tipo
+ \texttt{int *}) su cui sarà restituito il valore.
+\item[\constd{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
directory, mentre se applicata ad un dispositivo fallisce con un errore di
\errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
(cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
% 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
generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
al fatto che alle origini di Unix i progettisti considerarono che era
necessario trattare diversamente rispetto alle operazione di controllo delle
modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
-\func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
- usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
- l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
-ma le due funzioni sono rimaste.
+\func{ioctl} per i secondi, all'epoca tra l'altro i dispositivi che usavano
+\func{ioctl} erano sostanzialmente solo i terminali, il che spiega l'uso
+comune di \errcode{ENOTTY} come codice di errore. Oggi non è più così ma le
+due funzioni sono rimaste.
% TODO trovare qualche posto per la eventuale documentazione delle seguenti
% (bassa/bassissima priorità)
% EXT4_IOC_MOVE_EXT (dal 2.6.31)
-
-
-
+% EXT4_IOC_SHUTDOWN (dal 4.10), XFS_IOC_GOINGDOWN e futura FS_IOC_SHUTDOWN
+% ioctl di btrfs, vedi http://lwn.net/Articles/580732/
% \chapter{}
direttamente alle \textit{system call} messe a disposizione dal kernel.
Questa interfaccia però non provvede le funzionalità previste dallo standard
-ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
-queste, insieme alle altre funzioni definite dallo standard, vengono a
-costituire il nucleo\footnote{queste funzioni sono state implementate la prima
- volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente
- immutate.} delle \acr{glibc}.
-
+ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria.
+Queste funzioni di libreria, insieme alle altre funzioni definite dallo
+standard (che sono state implementate la prima volta da Ritchie nel 1976 e da
+allora sono rimaste sostanzialmente immutate), vengono a costituire il nucleo
+delle \acr{glibc} per la gestione dei file.
Esamineremo in questa sezione le funzioni base dell'interfaccia degli
\textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
all'ottenimento della massima efficienza.
Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
-\textit{file stream}, dato che non è più necessario doversi preoccupare
-dei dettagli della comunicazione con il tipo di hardware sottostante
-(come nel caso della dimensione dei blocchi del filesystem), ed un file
-può essere sempre considerato come composto da un flusso continuo (da
-cui il nome \textit{stream}) di dati.
+\textit{file stream}, dato che non è più necessario doversi preoccupare dei
+dettagli con cui viene gestita la comunicazione con l'hardware sottostante
+(come nel caso della dimensione dei blocchi del filesystem), ed un file può
+essere sempre considerato come composto da un flusso continuo di dati, da cui
+deriva appunto il nome \textit{stream}.
A parte i dettagli legati alla gestione delle operazioni di lettura e
-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_shared_access} a proposito dell'accesso
+scrittura, sia per quel che riguarda la bufferizzazione che le formattazioni,
+per tutto il resto 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_shared_access} a proposito dell'accesso
concorrente ed in sez.~\ref{sec:file_access_control} per il controllo di
accesso.
-\itindend{file~stream}
-
-
Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
-è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
+è stata chiamata \typed{FILE}, questi oggetti sono creati dalle funzioni di
libreria e contengono tutte le informazioni necessarie a gestire le operazioni
sugli \textit{stream}, come la posizione corrente, lo stato del buffer e degli
indicatori di stato e di fine del file.
Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
-queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
-usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa
-(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
-di \textit{stream}). Tutte le funzioni della libreria che operano sui file
-accettano come argomenti solo variabili di questo tipo, che diventa
-accessibile includendo l'header file \headfile{stdio.h}.
+queste strutture (che sono dei \textsl{tipi opachi}) ma usare sempre puntatori
+del tipo \texttt{FILE *} ottenuti dalla libreria stessa, tanto che in certi
+casi il termine di puntatore a file è diventato sinonimo di \textit{stream}.
+Tutte le funzioni della libreria che operano sui file accettano come argomenti
+solo variabili di questo tipo, che diventa accessibile includendo l'header
+file \headfile{stdio.h}.
+
+\itindend{file~stream}
Ai tre file descriptor standard (vedi tab.~\ref{tab:file_std_files}) aperti
per ogni processo, corrispondono altrettanti \textit{stream}, che
particolare per quello che riguarda l'aspetto della scrittura dei dati sul
file.
-I caratteri che vengono scritti su di uno \textit{stream} normalmente vengono
-accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione
- viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
- inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
-maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene
-anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
-sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
-inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura
-invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da
-parte di un altro processo) si potranno vedere solo le parti effettivamente
-scritte, e non quelle ancora presenti nel buffer.
+I dati che vengono scritti su di uno \textit{stream} normalmente vengono
+accumulati in un buffer e poi trasmessi in blocco, con l'operazione che viene
+usualmente chiamata \textsl{scaricamento} del buffer (dal termine inglese
+\textit{flush}) tutte le volte che questo viene riempito. Questa operazione
+avviene perciò in maniera asincrona rispetto alla scrittura. Un comportamento
+analogo avviene anche in lettura (cioè dal file viene letto un blocco di dati,
+anche se ne sono richiesti una quantità inferiore), ma la cosa ovviamente ha
+rilevanza inferiore, dato che i dati letti sono sempre gli stessi. In caso di
+scrittura invece, quando si ha un accesso contemporaneo allo stesso file (ad
+esempio da parte di un altro processo) si potranno vedere solo le parti
+effettivamente scritte, e non quelle ancora presenti nel buffer.
Per lo stesso motivo, in tutte le situazioni in cui si sta facendo
dell'input/output interattivo, bisognerà tenere presente le caratteristiche
delle operazioni di scaricamento dei dati, poiché non è detto che ad una
scrittura sullo \textit{stream} corrisponda una immediata scrittura sul
-dispositivo (la cosa è particolarmente evidente quando con le operazioni di
-input/output su terminale).
+dispositivo, e la cosa è particolarmente evidente con le operazioni di
+input/output sul terminale.
-Per rispondere ad esigenze diverse, lo standard definisce tre distinte
-modalità in cui può essere eseguita la bufferizzazione, delle quali
-occorre essere ben consapevoli, specie in caso di lettura e scrittura da
-dispositivi interattivi:
+Per rispondere ad esigenze diverse lo standard definisce tre distinte modalità
+in cui può essere eseguita la bufferizzazione, delle quali occorre essere ben
+consapevoli, specie in caso di lettura e scrittura da dispositivi interattivi:
\begin{itemize}
\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
caratteri vengono trasmessi direttamente al file non appena possibile
- (effettuando immediatamente una \func{write}).
-\item \textit{line buffered}: in questo caso i caratteri vengono
- normalmente trasmessi al file in blocco ogni volta che viene
- incontrato un carattere di \textit{newline} (il carattere ASCII
- \verb|\n|).
+ (effettuando immediatamente una \func{write});
+\item \textit{line buffered}: in questo caso i caratteri vengono normalmente
+ trasmessi al file in blocco ogni volta che viene incontrato un carattere di
+ \textit{newline} (il carattere ASCII \verb|\n|) cioè un a capo (in sostanza
+ quando si preme invio);
\item \textit{fully buffered}: in questo caso i caratteri vengono
trasmessi da e verso il file in blocchi di dimensione opportuna.
\end{itemize}
-Lo standard ANSI C specifica inoltre che lo standard output e lo
-standard input siano aperti in modalità \textit{fully buffered} quando
-non fanno riferimento ad un dispositivo interattivo, e che lo standard
+Lo standard ANSI C specifica inoltre che lo \textit{standard output} e lo
+\textit{standard input} siano aperti in modalità \textit{fully buffered}
+quando non fanno riferimento ad un dispositivo interattivo, e che lo standard
error non sia mai aperto in modalità \textit{fully buffered}.
Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
ancora più precisa, e cioè impone che lo standard error sia sempre
-\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
-rapidamente possibile) e che standard input e standard output siano aperti in
-modalità \textit{line buffered} quando sono associati ad un terminale (od
-altro dispositivo interattivo) ed in modalità \textit{fully buffered}
-altrimenti.
-
-Il comportamento specificato per standard input e standard output vale anche
-per tutti i nuovi \textit{stream} aperti da un processo; la selezione comunque
-avviene automaticamente, e la libreria apre lo \textit{stream} nella modalità
-più opportuna a seconda del file o del dispositivo scelto.
+\textit{unbuffered}, in modo che i messaggi di errore siano mostrati il più
+rapidamente possibile, e che \textit{standard input} \textit{standard output}
+siano aperti in modalità \textit{line buffered} quando sono associati ad un
+terminale (od altro dispositivo interattivo) ed in modalità \textit{fully
+ buffered} altrimenti.
+
+Il comportamento specificato per \textit{standard input} e \textit{standard
+ output} vale anche per tutti i nuovi \textit{stream} aperti da un processo;
+la selezione comunque avviene automaticamente, e la libreria apre lo
+\textit{stream} nella modalità più opportuna a seconda del file o del
+dispositivo scelto.
La modalità \textit{line buffered} è quella che necessita di maggiori
chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
-alla ricezione di un carattere di \textsl{a capo} (\textit{newline}); questo
-non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
-dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
-anche prima che sia stato inviato un carattere di \textit{newline}.
+alla ricezione di un carattere di \textsl{a capo} (il \textit{newline});
+questo non è vero in tutti i casi, infatti, dato che le dimensioni del buffer
+usato dalle librerie sono fisse, se le si eccedono si può avere uno scarico
+dei dati anche prima che sia stato inviato un carattere di \textit{newline}.
Un secondo punto da tenere presente, particolarmente quando si ha a che fare
con I/O interattivo, è che quando si effettua una lettura da uno
-\textit{stream} che comporta l'accesso al kernel\footnote{questo vuol dire che
- lo \textit{stream} da cui si legge è in modalità \textit{unbuffered}.} viene
-anche eseguito lo scarico di tutti i buffer degli \textit{stream} in
-scrittura.
-
-In sez.~\ref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
-opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
-dei dati.
-
+\textit{stream} che comporta l'accesso alle \textit{system call} del kernel,
+ad esempio se lo \textit{stream} da cui si legge è in modalità
+\textit{unbuffered}, viene anche eseguito lo scarico di tutti i buffer degli
+\textit{stream} in scrittura. In sez.~\ref{sec:file_buffering_ctrl} vedremo
+come la libreria definisca delle opportune funzioni per controllare le
+modalità di bufferizzazione e lo scarico dei dati.
Le funzioni che si possono usare per aprire uno \textit{stream} sono solo 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:
+ dello standard POSIX.1.} ed i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{stdio.h}
\func{freopen}.}
\end{funcproto}
-
Normalmente la funzione che si usa per aprire uno \textit{stream} è
\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).
+iniziare con almeno uno dei valori indicati in tab.~\ref{tab:file_fopen_mode},
+anche se 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.
+modalità indicata da \param{mode} ed associato allo \textit{stream} indicato
+dall'argomento \param{stream}, e se questo era uno \textit{stream} già aperto
+esso viene preventivamente chiuso e tutti i dati pendenti vengono scaricati.
Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
\func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
-usare gli \textit{stream} con file come le fifo o i socket, che non possono
+usare gli \textit{stream} con file come le \textit{fifo} o i socket, che non possono
essere aperti con le funzioni delle librerie standard del C.
\begin{table}[htb]
% \hline
\texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
creato se non esiste), l'accesso viene posto in sola
- scrittura, lo stream\textit{} è posizionato all'inizio del
+ scrittura, lo \textit{stream} è posizionato all'inizio del
file.\\
\texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
creato se non esiste), l'accesso viene posto in scrittura e
file.\\
% \hline
\texttt{a} & Il file viene aperto (o creato se non esiste) in
- \itindex{append~mode} \textit{append mode}, l'accesso viene
- posto in sola scrittura.\\
+ \textit{append mode}, l'accesso viene posto in sola
+ scrittura.\\
\texttt{a+}& Il file viene aperto (o creato se non esiste) in
- \itindex{append~mode} \textit{append mode}, l'accesso viene
- posto in lettura e scrittura.\\
+ \textit{append mode}, l'accesso viene posto in lettura e
+ scrittura.\\
\hline
\texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
\texttt{x} & L'apertura fallisce se il file esiste già. \\
Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
indicate dopo aver specificato il \param{mode} con uno dei valori di
tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
-evitare di sovrascrivere un file già esistente (è analoga all'uso
-dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
-esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
-fallisce.
+evitare di sovrascrivere un file già esistente (è analoga all'uso dell'opzione
+\const{O\_EXCL} in \func{open}): se il file specificato già esiste e si
+aggiunge questo carattere a \param{mode} la \func{fopen} fallisce.
Un'altra estensione serve a supportare la localizzazione, quando si
aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
Inoltre i modi \cmd{w} e \cmd{w+} non troncano il file. La posizione nello
\textit{stream} viene impostata a quella corrente nel file descriptor, e le
variabili di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono
-cancellate. Il file non viene duplicato e verrà chiuso alla chiusura dello
-\textit{stream}.
+cancellate. Il file non viene duplicato e verrà chiuso automaticamente alla
+chiusura dello \textit{stream}.
I nuovi file saranno creati secondo quanto visto in
sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
impostati al valore
\code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
-\val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
-il processo (si veda sez.~\ref{sec:file_perm_management}).
+\val{0666}) modificato secondo il valore della \textit{umask} per il processo
+(si veda sez.~\ref{sec:file_perm_management}). Una volta aperto lo
+\textit{stream}, si può cambiare la modalità di bufferizzazione (si veda
+sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato alcuna
+operazione di I/O sul file.
In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
sufficiente a garantire la sincronizzazione.
-Una volta aperto lo \textit{stream}, si può cambiare la modalità di
-bufferizzazione (si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non
-si è effettuato alcuna operazione di I/O sul file.
-
-Uno \textit{stream} viene chiuso con la funzione \funcd{fclose} il cui
-prototipo è:
+Una volta completate le operazioni su di esso uno \textit{stream} può essere
+chiuso con la funzione \funcd{fclose}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
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:
+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{Gestione dell'I/O e posizionamento 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{itemize}
+\item\textsl{binario} in cui si leggono e scrivono blocchi di dati di
+ dimensione arbitraria, (analogo della modalità ordinaria dell'I/O sui file
+ descriptor), trattato in sez.~\ref{sec:file_binary_io}.
+\item\textsl{a caratteri} in cui si legge e scrive un carattere alla volta,
+ con la bufferizzazione che viene gestita automaticamente dalla libreria,
+ trattato in sez.~\ref{sec:file_char_io}.
+\item\textsl{di linea} in cui si legge e scrive una linea alla volta,
+ (terminata dal carattere di newline \verb|'\n'|), trattato in
+ sez.~\ref{sec:file_line_io}.
+\end{itemize}
+a cui si aggiunge la modalità di input/output formattato, trattato in
+sez.~\ref{sec:file_formatted_io}.
+
+Ognuna di queste modalità utilizza per l'I/O delle funzioni specifiche che
+vedremo nelle sezioni citate, affronteremo qui tutte gli argomenti e le
+funzioni che si applicano in generale a tutte le modalità di I/O.
+
+A differenza di quanto avviene con l'interfaccia dei file descriptor, con gli
+\textit{stream} il raggiungimento della fine del file viene 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} definito anch'esso nell'header
+\headfile{stdlib.h}. La costante deve essere negativa perché in molte funzioni
+un valore positivo indica la quantità di dati scritti, le \acr{glibc} usano il
+valore $-1$, ma altre implementazioni possono avere valori diversi.
+
+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 sempre il valore impostato
+dalla \textit{system call} invocata internamente che ha riportato l'errore.
+
+Siccome la condizione di \textit{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}
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.
+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 su quanto avvenuto deve quindi
+essere effettuato ogni volta che si chiama una funzione di libreria.
Entrambi i flag (di errore e di \textit{end-of-file}) possono essere
cancellati usando la funzione \funcd{clearerr}, il cui prototipo è:
{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
-funzione esiste una analoga \funcm{clearerr\_unlocked} che non esegue il
-blocco dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
+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 funzione
+esiste una analoga \funcm{clearerr\_unlocked} (con lo stesso argomento e
+stessi valori di ritorno) che non esegue il blocco dello \textit{stream}
+(tratteremo il significato di blocco di uno \textit{stream} in
+sez.~\ref{sec:file_stream_thread}).
+
+Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
+all'interno di un file per effettuare operazioni di lettura o scrittura in un
+punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
+dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
+con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
+sistema Unix esistono vari tipi di file, come le \textit{fifo} ed i file di
+dispositivo (ad esempio i terminali), non è scontato che questo sia vero in
+generale, pur essendolo sempre nel caso di file di dati.
+
+Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
+abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero
+positivo, rappresentato dal tipo \type{off\_t}. Il problema è che alcune delle
+funzioni usate per il riposizionamento sugli \textit{stream} originano dalle
+prime versioni di Unix, in cui questo tipo non era ancora stato definito, e
+che in altri sistemi non è detto che la posizione su un file venga sempre
+rappresentata con il numero di caratteri dall'inizio: ad esempio nel VMS dove
+esistono i file a record (in cui cioè l'I/O avviene per blocchi, i record, di
+dimensione fissa), essa può essere rappresentata come un numero di record, più
+l'offset rispetto al record corrente.
+
+Tutto questo comporta la presenza di diverse funzioni che eseguono
+sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
+funzioni tradizionali usate per eseguire una modifica della posizione corrente
+sul file con uno \textit{stream} sono \funcd{fseek} e \funcd{rewind}, i
+rispettivi prototipi sono:
+
+\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 (vedi sez.~\ref{sec:file_lseek}). Anche gli argomenti, a parte il
+tipo, hanno esattamente lo stesso significato. In particolare \param{whence}
+deve assumere gli stessi valori già visti nella prima parte di
+tab.~\ref{tab:lseek_whence_values}. La funzione restituisce 0 in caso di
+successo e -1 in caso di errore.
+
+La funzione \func{rewind} riporta semplicemente la posizione corrente sul file
+all'inizio dello \textit{stream}, ma non è esattamente equivalente ad aver
+eseguito una \code{fseek(stream, 0L, SEEK\_SET)}, in quanto con l'uso della
+funzione vengono cancellati anche i flag di errore e di fine del file.
+
+Per ottenere la posizione corrente sul file di uno \textit{stream} lo standard
+ANSI C prescrive l'uso della funzione \funcd{ftell}, il cui prototipo è:
+
+\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}
+
+\noindent che restituisce la posizione come numero di byte dall'inizio dello
+\textit{stream}.
+
+Sia \func{fseek} che \func{ftell} esprimono la posizione nel file con un
+intero di tipo \ctyp{long}. Dato che in certi casi, ad esempio quando si usa
+un filesystem indicizzato a 64 bit su una macchina con architettura a 32 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
+\typed{fpos\_t}, ed i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int fsetpos(FILE *stream, fpos\_t *pos)}
+\fdesc{Imposta la posizione corrente sul file.}
+\fdecl{int fgetpos(FILE *stream, fpos\_t *pos)}
+\fdesc{Legge la posizione corrente sul file.}
+}
+
+{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
+precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
+\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
+gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
+posizione sul file viene espressa con un valore a 64 bit come accade nei
+sistemi più moderni.
+
+% TODO: mettere prototipi espliciti fseeko e ftello o menzione?
+
\subsection{Input/output binario}
lettura dei dati da un buffer verso un file e viceversa. In generale questa è
la modalità che si usa quando si ha a che fare con dati non formattati. Le due
funzioni che si usano per l'I/O binario sono \funcd{fread} ed \funcd{fwrite};
-i loro prototipi sono:
+i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{stdio.h}
elemento.
In realtà quello che conta nel trasferimento dei dati sono le dimensioni
-totali, che sono sempre pari al prodotto \code{size * nelem}; la sola
-differenza è che le funzioni non ritornano il numero di byte scritti,
-ma il numero di elementi.
+totali, che sono sempre pari al prodotto \code{size * nelem}, la differenza
+sta nel fatto che le funzioni non ritornano il numero di byte scritti, ma il
+numero di elementi (e con questo possono facilitare i conti).
La funzione \func{fread} legge sempre un numero intero di elementi, se
incontra la fine del file l'oggetto letto parzialmente viene scartato (lo
Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
-implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
-applicazioni \itindex{thread} \textit{multi-thread} (si veda
+implicito dello \textit{stream}, usato per dalla librerie per la gestione
+delle applicazioni \textit{multi-thread} (si veda
sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
\begin{funcproto}{
La seconda modalità di input/output è quella a caratteri, in cui si
trasferisce un carattere alla volta. Le funzioni per la lettura a
-caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, i
+caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, ed i
rispettivi prototipi sono:
\begin{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)}.
+\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
\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:
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
-si è letto, e non è necessario neanche avere letto nessun carattere
-prima di usare \func{ungetc}, ma di norma la funzione è intesa per
-essere usata per rimandare indietro l'ultimo carattere letto.
+Non è necessario che il carattere che si manda indietro sia l'ultimo che si è
+letto, e non è necessario neanche avere letto nessun carattere prima di usare
+\func{ungetc}, ma di norma la funzione è intesa per essere usata per rimandare
+indietro l'ultimo carattere letto. Nel caso \param{c} sia un \val{EOF} la
+funzione non fa nulla, e restituisce sempre \val{EOF}; così si può usare
+\func{ungetc} anche con il risultato di una lettura alla fine del file.
-Nel caso \param{c} sia un \val{EOF} la funzione non fa nulla, e
-restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
-con il risultato di una lettura alla fine del file.
+Se si è alla fine del file si può comunque rimandare indietro un carattere, il
+flag di \textit{end-of-file} verrà automaticamente cancellato perché c'è un
+nuovo carattere disponibile che potrà essere riletto successivamente.
-Se si è alla fine del file si può comunque rimandare indietro un
-carattere, il flag di end-of-file verrà automaticamente cancellato
-perché c'è un nuovo carattere disponibile che potrà essere riletto
-successivamente.
-
-Infine si tenga presente che \func{ungetc} non altera il contenuto del
-file, ma opera esclusivamente sul buffer interno. Se si esegue una
-qualunque delle operazioni di riposizionamento (vedi
-sez.~\ref{sec:file_fseek}) i caratteri rimandati indietro vengono
-scartati.
+Infine si tenga presente che \func{ungetc} non altera il contenuto del file,
+ma opera esclusivamente sul buffer interno. Se si esegue una qualunque delle
+operazioni di riposizionamento (vedi sez.~\ref{sec:file_io}) i caratteri
+rimandati indietro vengono scartati.
\subsection{Input/output di linea}
\label{sec:file_line_io}
La terza ed ultima modalità di input/output non formattato è quella di linea,
-in cui si legge o si scrive una riga alla volta; questa è una modalità molto
-usata per l'I/O da terminale, ma è anche quella che presenta le
+in cui si legge o si scrive una riga alla volta. Questa è la modalità usata
+normalmente per l'I/O da terminale, ed è anche quella che presenta le
caratteristiche più controverse.
Le funzioni previste dallo standard ANSI C per leggere una linea sono
\begin{funcproto}{
\fhead{stdio.h}
\fdecl{char *gets(char *string)}
-\fdesc{Legge una linea di testo dallo \textit{standard input}.}
+\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
-carattere \textit{newline}, \verb|'\n'|, quello mappato sul tasto di ritorno a
-capo della tastiera), ma \func{gets} sostituisce \verb|'\n'| con uno zero,
-mentre \func{fgets} aggiunge uno zero dopo il \textit{newline}, che resta
-dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
-viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
-L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
-funzione infatti non controlla il numero di byte letti, per cui nel caso la
-stringa letta superi le dimensioni del buffer, si avrà un
-\itindex{buffer~overflow} \textit{buffer overflow}, con sovrascrittura della
-memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
- in dettaglio e con molta efficacia nell'ormai famoso articolo di Aleph1
- \cite{StS}.}
+
+Entrambe le funzioni effettuano la lettura, dal file specificato \func{fgets},
+dallo \textit{standard input} \func{gets}, di una linea di caratteri terminata
+dal carattere ASCII di \textit{newline}, che come detto corrisponde a quello
+generato dalla pressione del tasto di invio sulla tastiera. Si tratta del
+carattere che indica la terminazione di una riga (in sostanza del carattere di
+``\textsl{a capo}'') che viene rappresentato nelle stringhe di formattazione
+che vedremo in sez.~\ref{sec:file_formatted_io} come
+``\verb|\n|''. Nell'esecuzione delle funzioni \func{gets} sostituisce
+``\verb|\n|'' con uno zero, mentre \func{fgets} aggiunge uno zero dopo il
+\textit{newline}, che resta dentro la stringa.
+
+\itindbeg{buffer~overflow}
+
+Se la lettura incontra la fine del file (o c'è un errore) viene restituito un
+puntatore \val{NULL}, ed il buffer \param{buf} non viene toccato. L'uso di
+\func{gets} è deprecato e deve essere assolutamente evitato, la funzione
+infatti non controlla il numero di byte letti, per cui nel caso la stringa
+letta superi le dimensioni del buffer, si avrà un \textit{buffer overflow},
+con sovrascrittura della memoria del processo adiacente al
+buffer.\footnote{questa tecnica è spiegata in dettaglio e con molta efficacia
+ nell'ormai famoso articolo di Aleph1 \cite{StS}.}
Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
una stringa sufficientemente lunga ed opportunamente forgiata per
-sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
-(supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
-far ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere
-uno \textit{shell code} cioè una sezione di programma che lancia una shell).
+sovrascrivere gli indirizzi di ritorno nello \textit{stack} (supposto che la
+\func{gets} sia stata chiamata da una subroutine), in modo da far ripartire
+l'esecuzione nel codice inviato nella stringa stessa, che in genere contiene
+uno \textit{shell code}, cioè una sezione di programma che lancia una shell da
+cui si potranno poi eseguire altri programmi.
+
+\itindend{buffer~overflow}
La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
-prende in input la dimensione del buffer \param{size}, che non verrà mai
+prende in ingresso la dimensione del buffer \param{size}, che non verrà mai
ecceduta in lettura. La funzione legge fino ad un massimo di \param{size}
-caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
-comporta che la stringa possa essere al massimo di \code{size-1} caratteri. Se
-la linea eccede la dimensione del buffer verranno letti solo \code{size-1}
-caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
-finale; sarà possibile leggere i rimanenti caratteri in una chiamata
+caratteri (\textit{newline} compreso), ed aggiunge uno zero di terminazione;
+questo comporta che la stringa possa essere al massimo di \code{size-1}
+caratteri. Se la linea eccede la dimensione del buffer verranno letti solo
+\code{size-1} caratteri, ma la stringa sarà sempre terminata correttamente con
+uno zero finale; sarà possibile leggere i rimanenti caratteri in una chiamata
successiva.
Per la scrittura di una linea lo standard ANSI C prevede altre due
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
-messaggi sullo standard output; la funzione prende una stringa terminata da
-uno zero ed aggiunge automaticamente il ritorno a capo. La differenza con
-\func{fputs} (a parte la possibilità di specificare un file diverso da
-\var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
-previsto esplicitamente.
+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 messaggi sullo \textit{standard
+ output}; la funzione prende una stringa terminata da uno zero ed aggiunge
+automaticamente il ritorno a capo. La differenza con \func{fputs} (a parte la
+possibilità di specificare un file diverso da \var{stdout}) è che quest'ultima
+non aggiunge il \textit{newline}, che deve essere previsto esplicitamente.
Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
linea esistono delle estensioni per leggere e scrivere linee di caratteri
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.
+scrive la linea \param{ws} di caratteri estesi sul file indicato
+da \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, \textit{newline}) è espresso in
+termini di caratteri estesi anziché di normali caratteri ASCII.
Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
\acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
Come abbiamo visto, le funzioni di lettura per l'input/output di linea
previste dallo standard ANSI C presentano svariati inconvenienti. Benché
-\func{fgets} non abbia i gravissimi problemi di \func{gets}, può
-comunque dare risultati ambigui se l'input contiene degli zeri; questi
-infatti saranno scritti sul buffer di uscita e la stringa in output
-apparirà come più corta dei byte effettivamente letti. Questa è una
-condizione che è sempre possibile controllare (deve essere presente un
-newline prima della effettiva conclusione della stringa presente nel
-buffer), ma a costo di una complicazione ulteriore della logica del
-programma. Lo stesso dicasi quando si deve gestire il caso di stringa
-che eccede le dimensioni del buffer.
+\func{fgets} non abbia i gravissimi problemi di \func{gets}, può comunque dare
+risultati ambigui se l'input contiene degli zeri; questi infatti saranno
+scritti sul buffer di uscita e la stringa in output apparirà come più corta
+dei byte effettivamente letti. Questa è una condizione che è sempre possibile
+controllare (deve essere presente un \textit{newline} prima della effettiva
+conclusione della stringa presente nel buffer), ma a costo di una
+complicazione ulteriore della logica del programma. Lo stesso dicasi quando si
+deve gestire il caso di stringa che eccede le dimensioni del buffer.
Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
funzioni per la gestione dell'input/output di linea, il cui uso permette di
risolvere questi problemi. L'uso di queste funzioni deve essere attivato
definendo la macro \macro{\_GNU\_SOURCE} prima di includere
\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 è:
+linea terminata da un \textit{newline}, esattamente allo stesso modo di
+\func{fgets}, il suo prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
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.
+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ò cioè passare come argomento primo
+argomento 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
-dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti
-come per entrambi gli argomenti si siano usati dei
-\itindex{value~result~argument} \textit{value result argument}, passando dei
-puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
-sez.~\ref{sec:proc_var_passing}).
+dimensione ed il nuovo puntatore vengono restituiti indietro, si noti infatti
+come entrambi gli argomenti siano dei \textit{value result argument}, per i
+quali vengono passati dei puntatori anziché i valori delle variabili, secondo
+quanto abbiamo descritto in sez.~\ref{sec:proc_var_passing}).
Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
\var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
puntatore all'inizio del testo della linea letta. Un esempio di codice può
essere il seguente:
\includecodesnip{listati/getline.c}
-e per evitare \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
-liberare \var{ptr} con una \func{free}.
-
-Il valore di ritorno della funzione indica il numero di caratteri letti
-dallo \textit{stream} (quindi compreso il newline, ma non lo zero di
-terminazione); questo permette anche di distinguere eventuali zeri letti
-dallo \textit{stream} da quello inserito dalla funzione per terminare la linea.
-Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
-un errore la funzione restituisce -1.
-
-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 è:
+e per evitare \textit{memory leak} occorre ricordarsi di liberare la memoria
+allocata dalla funzione eseguendo una \func{free} su \var{ptr}.
+
+Il valore di ritorno di \func{getline} indica il numero di caratteri letti
+dallo \textit{stream}, quindi compreso il \textit{newline}, ma non lo zero di
+terminazione. Questo permette anche di distinguere anche gli eventuali zeri
+letti come dati dallo \textit{stream} da quello inserito dalla funzione dopo
+il \textit{newline} per terminare la stringa. Se si è alla fine del file e
+non si è potuto leggere nulla o se c'è stato un errore la funzione restituisce
+$-1$.
+
+La seconda estensione GNU per la lettura con l'I/O di linea è una
+generalizzazione di \func{getline} per poter usare come separatore delle linee
+un carattere qualsiasi al posto del \textit{newline}. La funzione si chiama
+\funcd{getdelim} ed il suo prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
\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}).
+del carattere di \textit{newline} come separatore di linea. Il comportamento
+di \func{getdelim} è identico a quello di \func{getline}, che può essere
+implementata da \func{getdelim} passando ``\verb|\n|'' come valore
+dell'argomento \param{delim}.
-\subsection{L'input/output formattato}
+\subsection{Input/output formattato}
\label{sec:file_formatted_io}
L'ultima modalità di input/output è quella formattata, che è una delle
\begin{funcproto}{
\fhead{stdio.h}
\fdecl{int printf(const char *format, ...)}
-\fdesc{Scrive una stringa formattata sullo \textit{standard output}.}
+\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, ...)}
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.
+cui dovrà essere scritto il contenuto degli argomenti, il cui numero è
+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
-è:
+possibili \textit{buffer overflow}. Per questo motivo si consiglia l'uso
+dell'alternativa \funcd{snprintf}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
\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}).
+\noindent la funzione è identica a \func{sprintf}, ma non scrive
+su \param{str} più di \param{size} caratteri, garantendo così che il buffer
+non possa essere sovrascritto.
-\begin{table}[htb]
+\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|l|p{10cm}|}
\hline
\cmd{\%d} &\ctyp{int} & Stampa un numero intero in formato decimale
con segno.\\
- \cmd{\%i} &\ctyp{int} & Identico a \cmd{\%i} in output.\\
+ \cmd{\%i} &\ctyp{int} & Identico a \cmd{\%d} in output.\\
\cmd{\%o} &\ctyp{unsigned int}& Stampa un numero intero come ottale.\\
\cmd{\%u} &\ctyp{unsigned int}& Stampa un numero intero in formato
decimale senza segno.\\
\cmd{\%s} &\ctyp{char *} & Stampa una stringa.\\
\cmd{\%p} &\ctyp{void *} & Stampa il valore di un puntatore.\\
\cmd{\%n} &\ctyp{\&int} & Prende il numero di caratteri stampati finora.\\
- \cmd{\%\%}& & Stampa un \%.\\
+ \cmd{\%\%}& & Stampa un ``\texttt{\%}''.\\
\hline
\end{tabular}
\caption{Valori possibili per gli specificatori di conversione in una
\label{tab:file_format_spec}
\end{table}
-La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
-vengono passati invariati all'output, e da direttive di conversione, in cui
-devono essere sempre presenti il carattere \texttt{\%}, che introduce la
-direttiva, ed uno degli specificatori di conversione (riportati in
-tab.~\ref{tab:file_format_spec}) che la conclude.
+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 ``\textit{variadic}'', prendendo un
+numero di argomenti variabile che dipende appunto da quello che si è
+specificato in \param{format}.
+
+La stringa di formato è costituita da caratteri normali (tutti eccetto
+``\texttt{\%}''), che vengono passati invariati in uscita, e da direttive di
+conversione, in cui devono essere sempre presenti il carattere
+``\texttt{\%}'', che introduce la direttiva, ed uno degli specificatori di
+conversione (riportati in tab.~\ref{tab:file_format_spec}) che la conclude.
+
+Il formato di una direttiva di conversione prevede una serie di possibili
+elementi opzionali oltre al carattere ``\cmd{\%}'' e allo specificatore di
+conversione. In generale essa è sempre del tipo:
+\begin{Example}
+% [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
+\end{Example}
+in cui tutti i valori tranne il ``\texttt{\%}'' e lo specificatore di
+conversione sono opzionali (e per questo sono indicati fra parentesi quadre);
+si possono usare più elementi opzionali, nel qual caso devono essere
+specificati in questo ordine:
+\begin{itemize*}
+\item uno specificatore del parametro da usare (terminato da un carattere
+ ``\val{\$}''),
+\item uno o più flag (i cui valori possibili sono riassunti in
+ tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
+ conversione,
+\item uno specificatore di larghezza (un numero decimale), eventualmente
+ seguito (per i numeri in virgola mobile) da un specificatore di precisione
+ (un altro numero decimale),
+\item uno specificatore del tipo di dato, che ne indica la dimensione (i cui
+ valori possibili sono riassunti in tab.~\ref{tab:file_format_type}).
+\end{itemize*}
\begin{table}[htb]
\centering
\textbf{Valore} & \textbf{Significato}\\
\hline
\hline
- \val{\#} & Chiede la conversione in forma alternativa. \\
+ \val{\#} & Chiede la conversione in forma alternativa.\\
\val{0} & La conversione è riempita con zeri alla sinistra del valore.\\
\val{-} & La conversione viene allineata a sinistra sul bordo del campo.\\
\val{' '}& Mette uno spazio prima di un numero con segno di valore
\label{tab:file_format_flag}
\end{table}
-Il formato di una direttiva di conversione prevede una serie di possibili
-elementi opzionali oltre al \cmd{\%} e allo specificatore di conversione. In
-generale essa è sempre del tipo:
-\begin{center}
-\begin{verbatim}
-% [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
-\end{verbatim}
-\end{center}
-in cui tutti i valori tranne il \val{\%} e lo specificatore di conversione
-sono opzionali (e per questo sono indicati fra parentesi quadre); si possono
-usare più elementi opzionali, nel qual caso devono essere specificati in
-questo ordine:
-\begin{itemize*}
-\item uno specificatore del parametro da usare (terminato da un \val{\$}),
-\item uno o più flag (i cui valori possibili sono riassunti in
- tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
- conversione,
-\item uno specificatore di larghezza (un numero decimale), eventualmente
- seguito (per i numeri in virgola mobile) da un specificatore di precisione
- (un altro numero decimale),
-\item uno specificatore del tipo di dato, che ne indica la dimensione (i cui
- valori possibili sono riassunti in tab.~\ref{tab:file_format_type}).
-\end{itemize*}
-
-
-Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di
-manuale di \func{printf} e nella documentazione delle \acr{glibc}.
+Dettagli ulteriori sulle varie opzioni di stampa e su tutte le casistiche
+dettagliate dei vari formati possono essere trovati nella pagina di manuale di
+\func{printf} e nella documentazione delle \acr{glibc}.
\begin{table}[htb]
\centering
\cmd{L} & Una conversione in virgola mobile corrisponde a un
\ctyp{double}.\\
\cmd{q} & Sinonimo di \cmd{ll}.\\
- \cmd{j} & Una conversione intera corrisponde a un \type{intmax\_t} o
- \type{uintmax\_t}.\\
- \cmd{z} & Una conversione intera corrisponde a un \type{size\_t} o
- \type{ssize\_t}.\\
- \cmd{t} & Una conversione intera corrisponde a un \type{ptrdiff\_t}.\\
+ \cmd{j} & Una conversione intera corrisponde a un \ctyp{intmax\_t} o
+ \ctyp{uintmax\_t}.\\
+ \cmd{z} & Una conversione intera corrisponde a un \ctyp{size\_t} o
+ \ctyp{ssize\_t}.\\
+ \cmd{t} & Una conversione intera corrisponde a un \ctyp{ptrdiff\_t}.\\
\hline
\end{tabular}
\caption{Il modificatore di tipo di dato per il formato di \func{printf}}
\begin{funcproto}{
\fhead{stdio.h}
\fdecl{int vprintf(const char *format, va\_list ap)}
-\fdesc{Scrive una stringa formattata sullo \textit{standard output}.}
+\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}.}
+\fdesc{Scrive una stringa formattata su uno \textit{stream}.}
\fdecl{int vsprintf(char *str, const char *format, va\_list ap)}
\fdesc{Scrive una stringa formattata su un buffer.}
}
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
-l'esecuzione della funzione l'argomento
-\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
-\code{va\_end(ap)} ma in Linux questo non è necessario).
+variabile degli argomenti dovrà essere opportunamente trattata (l'argomento è
+esaminato in sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione
+l'argomento \param{ap} non sarà più utilizzabile (in generale dovrebbe essere
+eseguito un \code{va\_end(ap)} ma in Linux questo non è necessario).
Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
\funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
\func{vsprintf}.}
\end{funcproto}
-\noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
-overflow.
+\noindent in modo da evitare possibili \textit{buffer overflow}.
Per eliminare alla radice questi problemi, la \acr{glibc} supporta una
Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
-proposito dei \itindex{value~result~argument} \textit{value result argument})
-l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
-inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
-la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
- leak}.
+proposito dei \textit{value result argument}) l'indirizzo della stringa
+allocata automaticamente dalle funzioni. Occorre inoltre ricordarsi di
+invocare \func{free} per liberare detto puntatore quando la stringa non serve
+più, onde evitare \textit{memory leak}.
% TODO verificare se mettere prototipi di \func{dprintf} e \func{vdprintf}
\begin{funcproto}{
\fhead{stdio.h}
\fdecl{int scanf(const char *format, ...)}
-\fdesc{Esegue la scansione di dati dallo \textit{standard input}.}
+\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, ...)}
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
+da \param{format}, ed effettua le relative conversioni 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
facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
\cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
- \cite{flex}.} per generare un analizzatore lessicale o il
+ \cite{flex}.} per generare un analizzatore lessicale o
\cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo
manuale \cite{bison}.} per generare un parser.
-\subsection{Posizionamento su uno \textit{stream}}
-\label{sec:file_fseek}
-
-Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
-all'interno di un file per effettuare operazioni di lettura o scrittura in un
-punto prestabilito; sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo \textit{stream}, quando cioè si ha a che fare con
-quello che viene detto un file ad \textsl{accesso casuale}.\footnote{dato che
- in un sistema Unix esistono vari tipi di file, come le fifo ed i
- \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
- sia sempre vero.}
-
-In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
-espressa da un intero positivo, rappresentato dal tipo \type{off\_t}, il
-problema è che alcune delle funzioni usate per il riposizionamento sugli
-\textit{stream} originano dalle prime versioni di Unix, in cui questo tipo non
-era ancora stato definito, e che in altri sistemi non è detto che la posizione
-su un file venga sempre rappresentata con il numero di caratteri dall'inizio
-(ad esempio in VMS può essere rappresentata come numero di record, più
-l'offset rispetto al record corrente).
-
-Tutto questo comporta la presenza di diverse funzioni che eseguono
-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{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
-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{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{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
-precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
-\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
-gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
-posizione sul file viene espressa con un valore a 64 bit come accade nei
-sistemi più moderni.
-
-% TODO: mettere prototipi espliciti fseeko e ftello o menzione?
-
\section{Funzioni avanzate}
\label{sec:file_stream_adv_func}
In questa sezione esamineremo alcune funzioni avanzate che permettono di
-eseguire operazioni particolari sugli \textit{stream}, come leggerne gli
-attributi, controllarne le modalità di bufferizzazione, gestire direttamente i
-lock impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
+eseguire operazioni di basso livello nella gestione degli \textit{stream},
+come leggerne gli attributi, controllarne le modalità di bufferizzazione,
+gestire in maniera esplicita i lock impliciti presenti ad uso della
+programmazione \textit{multi-thread}.
\subsection{Le funzioni di controllo}
Al contrario di quanto avviene con i file descriptor, le librerie standard del
C non prevedono nessuna funzione come la \func{fcntl} per il controllo degli
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 è:
+descriptor, si può usare la funzione \funcd{fileno} per ottenere il valore di
+quest'ultimo; il suo prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
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
-\textit{stream}, ma non ci dà nessuna informazione riguardo alle proprietà
-dello \textit{stream} medesimo. Le \acr{glibc} però supportano alcune
-estensioni derivate da Solaris, che permettono di ottenere informazioni utili.
+In questo modo diventa possibile usare direttamente \func{fcntl} sul file
+descriptor sottostante, ma anche se questo permette di accedere agli attributi
+del file descriptor sottostante lo \textit{stream}, non ci dà nessuna
+informazione riguardo alle proprietà dello \textit{stream} medesimo. Le
+\acr{glibc} però supportano alcune estensioni derivate da Solaris, che
+permettono di ottenere informazioni utili relative allo \textit{stream}.
Ad esempio in certi casi può essere necessario sapere se un certo
\textit{stream} è accessibile in lettura o scrittura. In genere questa
-informazione non è disponibile, e si deve ricordare come il file è stato
-aperto. La cosa può essere complessa se le operazioni vengono effettuate in
-una subroutine, che a questo punto necessiterà di informazioni aggiuntive
-rispetto al semplice puntatore allo \textit{stream}; questo può essere evitato
+informazione non è disponibile, e ci si deve ricordare come è stato aperto il
+file. La cosa può essere complessa se le operazioni vengono effettuate in una
+subroutine, che a questo punto necessiterà di informazioni aggiuntive rispetto
+al semplice puntatore allo \textit{stream}. Questo problema può essere risolto
con le due funzioni \funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui
prototipi sono:
Però una volta che si sia aperto lo \textit{stream} (ma prima di aver compiuto
operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
-suo prototipo è:
+cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
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
+nella modalità indicata da \param{mode} con uno dei valori di
+tab.~\ref{tab:file_stream_buf_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
+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
-\textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
-dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
-funzione, può anche essere usata una \index{variabili!automatiche} variabile
-automatica. In \headfile{stdio.h} è definita la macro \const{BUFSIZ}, che
-indica le dimensioni generiche del buffer di uno \textit{stream}; queste
-vengono usate dalla funzione \func{setbuf}. Non è detto però che tale
-dimensione corrisponda sempre al valore ottimale (che può variare a seconda
-del dispositivo).
-
-Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
-(come delle scritture accidentali sul buffer) e non assicura la scelta delle
-dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
-di libreria, che sono in grado di farlo in maniera ottimale e trasparente
-all'utente (in quanto la deallocazione avviene automaticamente). Inoltre
-siccome alcune implementazioni usano parte del buffer per mantenere delle
-informazioni di controllo, non è detto che le dimensioni dello stesso
-coincidano con quelle su cui viene effettuato l'I/O.
-
\begin{table}[htb]
\centering
\footnotesize
\textbf{Valore} & \textbf{Modalità} \\
\hline
\hline
- \const{\_IONBF} & \textit{unbuffered}\\
- \const{\_IOLBF} & \textit{line buffered}\\
- \const{\_IOFBF} & \textit{fully buffered}\\
+ \constd{\_IONBF} & \textit{unbuffered}\\
+ \constd{\_IOLBF} & \textit{line buffered}\\
+ \constd{\_IOFBF} & \textit{fully buffered}\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{mode} di \func{setvbuf}
\label{tab:file_stream_buf_mode}
\end{table}
+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
+\textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
+dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
+funzione, può anche essere usata una variabile automatica. In
+\headfile{stdio.h} è definita la costante \constd{BUFSIZ}, che indica le
+dimensioni generiche del buffer di uno \textit{stream}, queste vengono usate
+dalla funzione \func{setbuf}. Non è detto però che tale dimensione
+corrisponda sempre al valore ottimale (che può variare a seconda del
+dispositivo).
+
+Dato che la procedura di allocazione manuale è macchinosa, comporta dei
+rischi, come delle scritture accidentali sul buffer, e non assicura la scelta
+delle dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle
+funzioni di libreria, che sono in grado di farlo in maniera ottimale e
+trasparente all'utente (in quanto la deallocazione avviene
+automaticamente). Inoltre siccome alcune implementazioni usano parte del
+buffer per mantenere delle informazioni di controllo, non è detto che le
+dimensioni dello stesso coincidano con quelle su cui viene effettuato l'I/O.
+
Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
usando il buffer allocato automaticamente dal sistema. Si potrà comunque
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:
+\funcd{setbuffer} e \funcd{setlinebuf}, i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{stdio.h}
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.
+vecchie librerie BSD, pertanto non è il caso di usarle se non per la
+portabilità su vecchi sistemi.
-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:
+Infine le \acr{glibc} provvedono le funzioni non standard, anche queste
+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{funcproto}{
\fhead{stdio\_ext.h}
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 è:
+\funcd{fflush}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
\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
-dello stream.
+\noindent anche di questa funzione esiste una analoga \func{fflush\_unlocked}
+(accessibile definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} o
+\macro{\_GNU\_SOURCE}) che non effettua il blocco dello \textit{stream}.
% TODO aggiungere prototipo \func{fflush\_unlocked}?
\textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
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 è:
+\textit{line buffered}. Per fare questo le \acr{glibc} supportano una
+estensione di Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio-ext.h}
\subsection{Gli \textit{stream} e i \textit{thread}}
\label{sec:file_stream_thread}
-\itindbeg{thread}
Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto
ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
funzioni di libreria durante la lettura e la scrittura di uno \textit{stream}
-devono essere opportunamente protette (in quanto il sistema assicura
-l'atomicità solo per le \textit{system call}). Questo viene fatto associando
-ad ogni \textit{stream} un opportuno blocco che deve essere implicitamente
+devono essere opportunamente protette, in quanto il sistema assicura
+l'atomicità solo per le \textit{system call}. Questo viene fatto associando ad
+ogni \textit{stream} un opportuno blocco che deve essere implicitamente
acquisito prima dell'esecuzione di qualunque operazione.
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} 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:
+\textit{stream} atomicamente. Per questo motivo le librerie provvedono anche
+le funzioni \funcd{flockfile} e \funcd{funlockfile} che permettono la gestione
+esplicita dei blocchi sugli \textit{stream}. Esse sono disponibili definendo
+\macrod{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
\begin{funcproto}{
\fhead{stdio.h}
\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.
+\textit{stream} \param{stream}, bloccandosi se questo risulta non è
+disponibile, mentre \func{funlockfile} rilascia un lock che si è
+precedentemente acquisito.
-Si può poi provare ad acquisire un lock senza bloccarsi con
-\funcd{ftrylockfile}, il cui prototipo è:
+Una terza funzione, che serve a provare ad acquisire un lock senza bloccarsi
+qualora non sia possibile, è \funcd{ftrylockfile}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
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.
+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
-lavoro abbastanza noioso; per questo motivo le \acr{glibc} forniscono al
-programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni
- introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
+lavoro abbastanza noioso. Per questo motivo le \acr{glibc} forniscono al
+programmatore pigro un'altra via, anche questa mutuata da estensioni
+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{funcproto}{
\fhead{stdio\_ext.h}
-\fdecl{int \_\_fsetlocking (FILE *stream, int type)}
+\fdecl{int \_\_fsetlocking(FILE *stream, int type)}
\fdesc{Specifica se abilitare il locking su uno \textit{stream}.}
}
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.
-\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
- dover gestire da solo il locking dello \textit{stream}.
-\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
- di blocco dello \textit{stream}.
-\end{basedescript}
+del locking a seconda del valore specificato con \param{type}, che può
+assumere uno dei valori indicati in tab.~\ref{tab:file_fsetlocking_type}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{FSETLOCKING\_INTERNAL}& Lo \textit{stream} userà da ora in poi il
+ blocco implicito predefinito.\\
+ \constd{FSETLOCKING\_BYCALLER}& Al ritorno della funzione sarà l'utente a
+ dover gestire da solo il locking dello
+ \textit{stream}.\\
+ \constd{FSETLOCKING\_QUERY} & Restituisce lo stato corrente della
+ modalità di blocco dello
+ \textit{stream}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{type} di \func{\_\_fsetlocking}
+ per l'impostazione delle modalità di bufferizzazione.}
+ \label{tab:file_fsetlocking_type}
+\end{table}
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}
-\itindend{thread}
-
-
%%% Local Variables:
%%% mode: latex
% LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile files fig flags
% LocalWords: locking fsetlocking type virtual operation dentry unistd sys AT
-% LocalWords: modification hole functions pathname EEXIST CREAT EINTR
+% LocalWords: modification hole functions pathname EEXIST CREAT EINTR attack
% 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: 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: everything framebuffer ENOTTY argp CDROM lsattr chattr magic TID
+% LocalWords: number FIOCLEX FIONCLEX FIOASYNC FIONBIO FIOSETOWN FIOGETOWN pid
% LocalWords: FIONREAD epoll FIOQSIZE side effects SAFE BYCALLER QUERY EACCES
-% LocalWords: EBUSY OpenBSD syncfs
-% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK
-% LocalWords: EFAULT
+% LocalWords: EBUSY OpenBSD syncfs futimes timespec only init ESRCH kill NTPL
+% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK PGRP SZ
+% LocalWords: EFAULT capabilities GETPIPE SETPIPE RESOURCE
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff