1 %% fileio.tex (merge fileunix.tex - filestd.tex)
3 %% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{La gestione dei contenuti dei file}
13 \label{cha:file_IO_interface}
16 Esamineremo in questo capitolo le due interfacce di programmazione che
17 consentono di gestire i dati mantenuti nei file. Cominceremo con quella nativa
18 del sistema, detta dei \itindex{file~descriptor} \textit{file descriptor}, che
19 viene fornita direttamente dalle \textit{system call} e che non prevede
20 funzionalità evolute come la bufferizzazione o funzioni di lettura o scrittura
21 formattata. Esamineremo poi anche l'interfaccia definita dallo standard ANSI
22 C, che viene chiamata dei \textit{file stream} o anche più brevemente degli
23 \textit{stream}. Per entrambe dopo una introduzione alle caratteristiche
24 generali tratteremo le funzioni base per la gestione dell'I/O, lasciando per
25 ultime le caratteristiche più avanzate.
28 \section{L'interfaccia dei \textit{file descriptor}}
29 \label{sec:file_unix_interface}
32 Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposione
33 tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
34 serie di \textit{system call} che consentono di operare sui file in maniera
35 generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
36 file nel precedente capitolo, vedremo quelle che si applicano al contenuto dei
37 file in questa sezione, iniziando con una breve introduzione sull'architettura
38 dei \textit{file descriptor} per poi trattare le funzioni di base e le
39 modalità con cui consentono di gestire i dati memorizzati sui file.
42 \subsection{I \textit{file descriptor}}
45 \itindbeg{file~descriptor}
47 L'accesso al contenuto dei file viene effettuato, sia pure con differenze
48 nella realizzazione pratica, in maniera sostanzialmente identica in tutte le
49 implementazioni di un sistema unix-like, ricorrendo a quella che viene
50 chiamata l'interfaccia dei \textit{file descriptor}.
52 Per poter accedere al contenuto di un file occorre creare un canale di
53 comunicazione con il kernel che renda possibile operare su di esso. Questo si
54 fa aprendo il file con la funzione \func{open} (vedi sez.~\ref{sec:file_open})
55 che provvederà a localizzare \itindex{inode} l'inode del file e inizializzare
56 i puntatori che rendono disponibili le funzioni che il
57 \itindex{Virtual~File~System} VFS mette a disposizione (quelle di
58 tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
59 file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
60 impedendo ogni ulteriore operazione.
62 All'interno di ogni processo i file aperti sono identificati da un numero
63 intero non negativo, che viene chiamato \textit{file descriptor}. Quando un
64 file viene aperto la funzione \func{open} restituisce questo numero, tutte le
65 ulteriori operazioni dovranno essere compiute specificando questo stesso
66 numero come argomento alle varie funzioni dell'interfaccia.
68 Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
69 kernel gestisce l'interazione fra processi e file. Abbiamo già accennato in
70 sez.~\ref{sec:proc_hierarchy} come il kernel mantenga un elenco di tutti
71 processi nella cosiddetta \itindex{process~table} \textit{process table}. Lo
72 stesso, come accennato in sez.~\ref{sec:file_vfs_work}, vale anche per tutti i
73 file che sono stati aperti, il cui elenco viene mantenuto nella cosiddetta
74 \itindex{file~table} \textit{file table}.
76 La \itindex{process~table} \textit{process table} è una tabella che contiene
77 una voce per ciascun processo attivo nel sistema. Ciascuna voce è costituita
78 da una struttura di tipo \kstruct{task\_struct} nella quale sono raccolte
79 tutte le informazioni relative al processo, fra queste informazioni c'è anche
80 il puntatore ad una ulteriore struttura di tipo
81 \kstruct{files\_struct},\footnote{la definizione corrente di questa struttura
82 si trova nel file \texttt{include/linux/fdtable.h} dei sorgenti del kernel,
83 quella mostrata in fig.~\ref{fig:file_proc_file} è una versione pesantemente
84 semplificata.} in cui sono contenute le informazioni relative ai file che il
87 La \itindex{file~table} \textit{file table} è invece una tabella che contiene
88 una voce per ciascun file che è stato aperto nel sistema. Come accennato in
89 sez.~\ref{sec:file_vfs_work} per ogni file aperto viene allocata una struttura
90 \kstruct{file} e la \textit{file table} è costituita da un elenco di puntatori
91 a ciascuna di queste strutture, che come illustrato in
92 fig.~\ref{fig:kstruct_file}, contengono le informazioni necessario per la
93 gestione dei contenuti del file, fra cui:
95 \item lo stato del file nel campo \var{f\_flags}.
96 \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
98 \item un puntatore alla struttura \kstruct{inode} che identifica
99 \itindex{inode} l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in
100 realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta
101 a sua volta \itindex{inode} all'\textit{inode} passando per la nuova
103 \item un puntatore \var{f\_op} alla tabella delle funzioni che si possono
104 usare sul file.\footnote{quelle della struttura \kstruct{file\_operation},
105 descritte sommariamente in tab.~\ref{tab:file_file_operations}.}
110 \includegraphics[width=13cm]{img/procfile}
111 \caption{Schema della architettura dell'accesso ai file attraverso
112 l'interfaccia dei \textit{file descriptor}.}
113 \label{fig:file_proc_file}
116 In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui
117 è illustrata questa architettura, ed in cui si sono evidenziate le
118 interrelazioni fra la \itindex{file~table} \textit{file table}, la
119 \itindex{process~table} \textit{process table} e le varie strutture di dati
120 che il kernel mantiene per ciascun file e ciascun processo.
122 Come si può notare alla fine il collegamento che consente di porre in
123 relazione i file ed i processi è effettuato attraverso i dati mantenuti nella
124 struttura \kstruct{files\_struct}, essa infatti contiene alcune informazioni
127 \item i flag relativi ai file aperti dal processo.
128 \item il numero di file aperti dal processo.
129 \item una tabella di puntatori alla relativa voce nella \itindex{file~table}
130 \textit{file table} per ciascun file aperto.
133 In questa infrastruttura un \textit{file descriptor} non è altro che l'intero
134 positivo che indicizza quest'ultima tabella, grazie al quale si può recuperare
135 il puntatore alla struttura \kstruct{file} nella \itindex{file~table}
136 \textit{file table} corrispondente al file che è stato aperto dal processo e a
137 cui era stato assegnato questo indice. Ma una volta indicato col \textit{file
138 descriptor} qual'è la struttura \kstruct{file} nella \textit{file table}
139 corrispondente al file voluto, il kernel potrà usare le funzioni messe
140 disposizione dal VFS per eseguire sul file tutte le operazioni necessarie.
142 Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo
143 \textit{file descriptor} libero nella tabella, e per questo motivo essi
144 vengono assegnati in successione tutte le volte che si apre un nuovo file,
145 posto che non ne sia stato chiuso nessuno in precedenza.
147 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
148 processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
149 quanto appena detto, avranno come \itindex{file~descriptor} \textit{file
150 descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione,
151 essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
152 portare a gravi problemi di interoperabilità.
154 Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
155 il file da cui un processo si aspetta di ricevere i dati in ingresso. Il
156 secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
157 si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
158 \textit{standard error}, su cui viene inviata l'uscita relativa agli errori.
159 Nel caso della shell tutti questi file sono associati al terminale di
160 controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e
161 alla scrittura sul terminale per l'uscita. Lo standard POSIX.1 provvede, al
162 posto dei valori numerici, tre costanti simboliche, definite in
163 tab.~\ref{tab:file_std_files}.
168 \begin{tabular}[c]{|l|l|}
170 \textbf{File} & \textbf{Significato} \\
173 \const{STDIN\_FILENO} & \textit{file descriptor} dello \textit{standard
175 \const{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
177 \const{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
181 \caption{Costanti definite in \headfile{unistd.h} per i file standard aperti
182 alla creazione di ogni processo.}
183 \label{tab:file_std_files}
186 In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa
187 rispetto a quella usuale della shell, in cui tutti e tre questi file fanno
188 riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata
189 la situazione di un programma in cui lo \textit{standard input} è associato ad
190 un certo file mentre lo \textit{standard output} e lo \textit{standard error}
191 sono entrambi associati ad un altro file.
193 Si noti come questi ultimi, pur utilizzando strutture \kstruct{file} diverse,
194 essendo il file che è stato aperto lo stesso, fanno a loro volta riferimento
195 allo stesso \itindex{inode} \textit{inode}. Questo è quello che avviene
196 normalmente quando si apre più volte lo stesso file.
198 Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file
199 table} una situazione analoga di quella delle voci di una directory, con la
200 possibilità di avere più voci che fanno riferimento allo stesso
201 \itindex{inode} \textit{inode}. L'analogia è in realtà molto stretta perché
202 quando si cancella un file, il kernel verifica anche che non resti nessun
203 riferimento in una una qualunque voce della \itindex{file~table} \textit{file
204 table} prima di liberare le risorse ad esso associate e disallocare il
205 relativo \itindex{inode} \textit{inode}.
207 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
208 numero di file aperti era anche soggetto ad un limite massimo dato dalle
209 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
210 descriptor dentro \kstruct{files\_struct}; questo limite intrinseco nei kernel
211 più recenti non sussiste più, dato che si è passati da un vettore ad una
212 lista, ma restano i limiti imposti dall'amministratore (vedi
213 sez.~\ref{sec:sys_limits}).
217 \subsection{Apertura e creazione di un file}
218 \label{sec:file_open}
220 La funzione di sistema \funcd{open} è la funzione fondamentale
221 dell'interfaccia di gestione dei file su Unix, ed è quella che dato un
222 \textit{pathname} consente di ottenere un file descriptor ``\textsl{aprendo}''
223 il file corrispondente,\footnote{è questa funzione che alloca la struttura
224 \kstruct{file}, la inserisce nella \itindex{file~table} \textit{file table}
225 e crea il riferimento nella \kstruct{files\_struct} del processo.} il suo
232 \fdecl{int open(const char *pathname, int flags)}
233 \fdecl{int open(const char *pathname, int flags, mode\_t mode)}
235 \fdesc{Apre un file.}
238 {La funzione ritorna il file descriptor in caso di successo e $-1$ per un
239 errore, nel qual caso \var{errno} assumerà uno dei valori:
241 \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
242 \const{O\_CREAT} e \const{O\_EXCL}.
243 \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
244 l'accesso in scrittura.
245 \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
246 \param{pathname} non è una directory.
247 \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
248 \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
249 processo o \param{pathname} è un file di dispositivo ma il dispositivo è
251 \item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
252 dispositivo che non esiste.
253 \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
254 di un programma in esecuzione.
255 \item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel
256 risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
257 \param{pathname} è un link simbolico.
259 ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
260 \errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
261 \errval{EMFILE} e \errval{ENFILE} nel loro significato generico.}
264 La funzione apre il file indicato da \param{pathname} nella modalità indicata da
265 \param{flags}. Essa può essere invocata in due modi diversi, specificando
266 opzionalmente un terzo argomento \param{mode}. Qualora il file non esista e
267 venga creato, questo argomento consente di indicare quali permessi dovranno
268 essergli assegnati. La funzione restituisce il primo file descriptor libero.
270 Quest'ultima caratteristica permette di prevedere sempre qual è il valore del
271 file descriptor che si otterrà al ritorno di \func{open}, e viene talvolta
272 usata da alcune applicazioni per sostituire i file corrispondenti ai file
273 standard visti in tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo
274 standard input e si apre subito dopo un nuovo file questo diventerà il nuovo
275 standard input (avrà cioè il file descriptor 0).
277 Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
278 altro processo (torneremo sulla condivisione dei file, in genere accessibile
279 dopo una \func{fork}, in sez.~\ref{sec:file_sharing}) ed è impostato per
280 restare aperto attraverso una \func{exec} (come accennato in
281 sez.~\ref{sec:proc_exec}). L'\textit{offset} è impostato all'inizio del file.
283 L'argomento opzionale \param{mode} indica i permessi con cui il file viene
284 creato ed i valori possibili sono gli stessi già visti in
285 sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
286 delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
287 filtrati dal valore di \itindex{umask} \textit{umask} (vedi
288 sez.~\ref{sec:file_perm_management}) per il processo.
290 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
291 dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
292 il cosiddetto flag di stato del file (o \textit{file status flag}), che è
293 mantenuto nel campo \var{f\_flags} della struttura \kstruct{file} (al solito
294 si veda lo schema di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre
295 categorie principali:
297 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
298 si accederà al file: i valori possibili sono lettura, scrittura o
299 lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
300 si apre un file. Vengono impostati alla chiamata da \func{open}, e possono
301 essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
302 ma non possono essere modificati.
303 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
304 \item[\const{O\_RDONLY}] Apre il file in sola lettura, le \acr{glibc}
305 definiscono anche \const{O\_READ} come sinonimo.
306 \item[\const{O\_WRONLY}] Apre il file in sola scrittura, le \acr{glibc}
307 definiscono anche \const{O\_WRITE} come sinonimo.
308 \item[\const{O\_RDWR}] Apre il file sia in lettura che in scrittura.
310 \item \textsl{i bit delle modalità di operazione}: permettono di specificare
311 alcune caratteristiche del comportamento delle future operazioni sul file
312 (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
313 status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
314 possono essere riletti e modificati (insieme alle caratteristiche operative
315 che controllano) con una \func{fcntl}.
316 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
318 \item[\const{O\_CREAT}] Se il file non esiste verrà creato, con le regole di
319 titolarità del file viste in sez.~\ref{sec:file_ownership_management}. Con
320 questa opzione l'argomento \param{mode} deve essere specificato.
322 \item[\const{O\_EXCL}] Usato in congiunzione con \const{O\_CREAT} fa sì che la
323 precedente esistenza del file diventi un errore\footnote{la pagina di
324 manuale di \func{open} segnala che questa opzione è difettosa su NFS, e
325 che i programmi che la usano per stabilire un \index{file!di lock}
326 \textsl{file di lock} possono incorrere in una \itindex{race~condition}
327 \textit{race condition}. Si consiglia come alternativa di usare un file
328 con un nome univoco e la funzione \func{link} per verificarne l'esistenza
329 (vedi sez.~\ref{sec:ipc_file_lock}).} che fa fallire \func{open} con
332 \item[\const{O\_NONBLOCK}] Apre il file in modalità non bloccante, e comporta
333 che \func{open} ritorni immediatamente anche quando dovrebbe bloccarsi
334 (l'opzione ha senso solo per le fifo, vedi sez.~\ref{sec:ipc_named_pipe}).
336 \item[\const{O\_NOCTTY}] Se \param{pathname} si riferisce ad un dispositivo di
337 terminale, questo non diventerà il terminale di controllo, anche se il
338 processo non ne ha ancora uno (si veda sez.~\ref{sec:sess_ctrl_term}).
340 \item[\const{O\_SHLOCK}] Apre il file con uno shared lock (vedi
341 sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux.
343 \item[\const{O\_EXLOCK}] Apre il file con un lock esclusivo (vedi
344 sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux.
346 \item[\const{O\_TRUNC}] Se usato su un file di dati aperto in scrittura, ne
347 tronca la lunghezza a zero; con un terminale o una fifo viene ignorato,
348 negli altri casi il comportamento non è specificato.
350 \item[\const{O\_NOFOLLOW}] Se \param{pathname} è un link simbolico la chiamata
351 fallisce. Questa è un'estensione BSD aggiunta in Linux dal kernel
352 2.1.126. Nelle versioni precedenti i link simbolici sono sempre seguiti, e
353 questa opzione è ignorata.
355 \item[\const{O\_DIRECTORY}] Se \param{pathname} non è una directory la
356 chiamata fallisce. Questo flag è specifico di Linux ed è stato introdotto
357 con il kernel 2.1.126 per evitare dei \itindex{Denial~of~Service~(DoS)}
358 \textit{DoS}\footnote{acronimo di \itindex{Denial~of~Service~(DoS)}
359 \textit{Denial of Service}, si chiamano così attacchi miranti ad impedire
360 un servizio causando una qualche forma di carico eccessivo per il sistema,
361 che resta bloccato nelle risposte all'attacco.} quando \func{opendir}
362 viene chiamata su una fifo o su un dispositivo associato ad una unità a
363 nastri, non deve dispositivo a nastri; non deve essere utilizzato
364 al di fuori dell'implementazione di \func{opendir}.
366 \item[\const{O\_LARGEFILE}] Nel caso di sistemi a 32 bit che supportano file
367 di grandi dimensioni consente di aprire file le cui dimensioni non possono
368 essere rappresentate da numeri a 31 bit.
370 \item \textsl{i bit delle modalità di apertura}: permettono di specificare
371 alcune delle caratteristiche del comportamento di \func{open} quando viene
372 eseguita. Hanno effetto solo al momento della chiamata della funzione e non
373 sono memorizzati né possono essere riletti.
374 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
376 \item[\const{O\_APPEND}] Il file viene aperto in \itindex{append~mode}
377 \textit{append mode}. Prima di ciascuna scrittura la posizione corrente
378 viene sempre impostata alla fine del file. Con NFS si può avere una
379 corruzione del file se più di un processo scrive allo stesso
380 tempo.\footnote{il problema è che NFS non supporta la scrittura in
381 \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
382 questo comporta la possibilità di una \itindex{race~condition}
383 \textit{race condition}, vedi sez.~\ref{sec:file_atomic}.}
385 \item[\const{O\_NONBLOCK}] Il file viene aperto in modalità non bloccante per
386 le operazioni di I/O (che tratteremo in sez.~\ref{sec:file_noblocking}):
387 questo significa il fallimento di \func{read} in assenza di dati da leggere
388 e quello di \func{write} in caso di impossibilità di scrivere
389 immediatamente. Questa modalità ha senso solo per le fifo e per alcuni file
392 \item[\const{O\_NDELAY}] In Linux è sinonimo di
393 \const{O\_NONBLOCK}.\footnote{l'opzione origina da SVr4, dove però causava
394 il ritorno da una \func{read} con un valore nullo e non con un errore,
395 questo introduce un'ambiguità, dato che come vedremo in
396 sez.~\ref{sec:file_read} il ritorno di zero da parte di \func{read} ha il
397 significato di una \textit{end-of-file}.}
399 \item[\const{O\_ASYNC}] Apre il file per l'I/O in modalità asincrona (vedi
400 sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il
401 segnale \signal{SIGIO} tutte le volte che sono disponibili dati in input sul
404 \item[\const{O\_SYNC}] Apre il file per l'input/output sincrono: ogni
405 \func{write} bloccherà fino al completamento della scrittura di tutti i dati
406 sull'hardware sottostante.
408 \item[\const{O\_FSYNC}] Sinonimo di \const{O\_SYNC}, usato da BSD.
410 \item[\const{O\_DSYNC}] Variante di I/O sincrono definita da POSIX; presente
411 dal kernel 2.1.130 come sinonimo di \const{O\_SYNC}.
413 \item[\const{O\_RSYNC}] Variante analoga alla precedente, trattata allo stesso
416 \item[\const{O\_NOATIME}] Blocca l'aggiornamento dei tempi di accesso dei file
417 (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa
418 funzionalità non è disponibile per il singolo file ma come opzione generale
419 da specificare in fase di montaggio.
421 \item[\const{O\_DIRECT}] Esegue l'I/O direttamente dai buffer in user space in
422 maniera sincrona, in modo da scavalcare i meccanismi di caching del
423 kernel. In genere questo peggiora le prestazioni tranne quando le
424 applicazioni ottimizzano il proprio caching.\footnote{l'opzione è stata
425 introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad
426 alcuni programmi (in genere database) la gestione diretta della
427 bufferizzazione dell'I/O in quanto essi sono in grado di ottimizzarla al
428 meglio per le loro prestazioni; l'opzione è presente anche in FreeBSD,
429 senza limiti di allineamento dei buffer. In Linux è stata introdotta con
430 il kernel 2.4.10, le versioni precedenti la ignorano.} Per i kernel della
431 serie 2.4 si deve garantire che i buffer in user space siano allineati alle
432 dimensioni dei blocchi del filesystem; per il kernel 2.6 basta che siano
433 allineati a multipli di 512 byte.
435 \item[\const{O\_CLOEXEC}] Attiva la modalità di \itindex{close-on-exec}
436 \textit{close-on-exec} (vedi sez.~\ref{sec:file_sharing} e
437 \ref{sec:file_fcntl}).\footnote{introdotto con il kernel 2.6.23, per evitare
438 una \itindex{race~condition} \textit{race condition} che si può verificare
439 con i \itindex{thread} \textit{thread}, fra l'apertura del file e
440 l'impostazione della suddetta modalità con \func{fcntl}.}
445 %TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
446 % nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
449 In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
450 secondo le tre modalità appena elencate, le costanti mnemoniche associate a
451 ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
452 un OR aritmetico per costruire il valore (in forma di maschera binaria)
453 dell'argomento \param{flags} da passare alla \func{open}. I due flag
454 \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di
455 Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli
458 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
459 \func{open} erano solo quelli relativi alle modalità di accesso del file. Per
460 questo motivo per creare un nuovo file c'era una system call apposita,
461 \funcd{creat}, il cui prototipo è:
465 \fdecl{int creat(const char *pathname, mode\_t mode)}
466 \fdesc{Crea un nuovo file vuoto.}
469 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
470 caso \var{errno} assumerà gli stessi valori che si otterebbero con
475 La funzione crea un nuovo file vuoto, con i permessi specificati
476 dall'argomento \param{mode}. È del tutto equivalente a \code{open(filedes,
477 O\_CREAT|O\_WRONLY|O\_TRUNC, mode)} e resta solo per compatibilità con i
481 \subsection{La funzione \func{close}}
482 \label{sec:file_close}
484 La funzione \funcd{close} permette di chiudere un file, in questo modo il file
485 descriptor ritorna disponibile; il suo prototipo è:
486 \begin{prototype}{unistd.h}{int close(int fd)}
487 Chiude il descrittore \param{fd}.
489 \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
490 errore, con \var{errno} che assume i valori:
492 \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
493 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
495 ed inoltre \errval{EIO}.}
498 La chiusura di un file rilascia ogni blocco (il \textit{file locking}
499 \itindex{file~locking} è trattato in sez.~\ref{sec:file_locking}) che il
500 processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
501 riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
502 \itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
503 descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
506 Si ricordi che quando un processo termina anche tutti i suoi file descriptor
507 vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
508 esplicitamente \func{close}. In genere comunque chiudere un file senza
509 controllarne lo stato di uscita è errore; infatti molti filesystem
510 implementano la tecnica del \textit{write-behind}, per cui una \func{write}
511 può avere successo anche se i dati non sono stati scritti, un eventuale errore
512 di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
513 questo motivo non effettuare il controllo può portare ad una perdita di dati
514 inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
515 e le quote su disco.}
517 In ogni caso una \func{close} andata a buon fine non garantisce che i dati
518 siano stati effettivamente scritti su disco, perché il kernel può decidere di
519 ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
520 \func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
521 \emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
522 comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
523 dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
524 di ripetere tre volte il comando prima di eseguire lo shutdown).
527 \subsection{La gestione della posizione nel file}
528 \label{sec:file_lseek}
530 Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
531 una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
532 mantenuto nel campo \var{f\_pos} di \kstruct{file}) espressa da un numero intero
533 positivo come numero di byte dall'inizio del file. Tutte le operazioni di
534 lettura e scrittura avvengono a partire da questa posizione che viene
535 automaticamente spostata in avanti del numero di byte letti o scritti.
537 In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
538 \const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
539 file. È possibile impostarla ad un valore qualsiasi con la funzione
540 \funcd{lseek}, il cui prototipo è:
542 \headdecl{sys/types.h}
544 \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
545 Imposta la posizione attuale nel file.
547 \bodydesc{La funzione ritorna il valore della posizione corrente in caso di
548 successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
551 \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
552 \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
553 \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
556 ed inoltre \errval{EBADF}.}
559 La nuova posizione è impostata usando il valore specificato da \param{offset},
560 sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
561 seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
562 questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
563 \const{L\_SET}, \const{L\_INCR} e \const{L\_XTND}.}:
564 \begin{basedescript}{\desclabelwidth{2.0cm}}
565 \item[\const{SEEK\_SET}] si fa riferimento all'inizio del file: il valore
566 (sempre positivo) di \param{offset} indica direttamente la nuova posizione
568 \item[\const{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
569 ad essa viene sommato \param{offset} (che può essere negativo e positivo)
570 per ottenere la nuova posizione corrente.
571 \item[\const{SEEK\_END}] si fa riferimento alla fine del file: alle dimensioni
572 del file viene sommato \param{offset} (che può essere negativo e positivo)
573 per ottenere la nuova posizione corrente.
576 % TODO, trattare, SEEK_HOLE e SEEK_DATA, inclusi nel kernel 3.1, vedi
577 % http://lwn.net/Articles/439623/
580 Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
581 file, si limita a modificare la posizione corrente (cioè il valore
582 \var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che
583 la funzione ritorna la nuova posizione, usando il valore zero
584 per \param{offset} si può riottenere la posizione corrente nel file chiamando
585 la funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
587 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
588 la successiva scrittura avvenga alla fine del file, infatti se questo è stato
589 aperto anche da un altro processo che vi ha scritto, la fine del file può
590 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
591 (questa è una potenziale sorgente di \itindex{race~condition} \textit{race
592 condition}, vedi sez.~\ref{sec:file_atomic}).
594 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
595 questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
596 per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
597 non supportano questa funzione, come ad esempio per i file di
598 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
599 ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
600 POSIX però non specifica niente in proposito. Inoltre alcuni
601 \index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
602 un errore ma restituiscono un valore indefinito.
604 \itindbeg{sparse~file}
606 Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
607 con \func{lseek} è possibile impostare una posizione anche oltre la corrente
608 fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
609 partire da detta posizione. In questo caso si ha quella che viene chiamata la
610 creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
611 che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
612 effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
613 scritta dopo lo spostamento, non corrisponda ad una allocazione effettiva di
614 spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
617 Questa è una delle caratteristiche spcifiche della gestione dei file di un
618 sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
619 chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
620 file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
621 struttura di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail},
622 quello che accade è che nell'\textit{inode} del file viene segnata
623 l'allocazione di un blocco di dati a partire dalla nuova posizione, ma non
624 viene allocato nulla per le posizioni intermedie; in caso di lettura
625 sequenziale del contenuto del file il kernel si accorgerà della presenza del
626 buco, e restituirà degli zeri come contenuto di quella parte del file.
628 Questa funzionalità comporta una delle caratteristiche della gestione dei file
629 su Unix che spesso genera più confusione in chi non la conosce, per cui
630 sommando le dimensioni dei file si può ottenere, se si hanno molti
631 \textit{sparse file}, un totale anche maggiore della capacità del proprio
632 disco e comunque maggiore della dimensione che riporta un comando come
633 \cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
634 effettivamente allocati per il file.
636 Questo avviene proprio perché in un sistema unix-like la dimensione di un file
637 è una caratteristica del tutto indipendente dalla quantità di spazio disco
638 effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
639 proprietà del file. La dimensione viene aggiornata automaticamente quando si
640 estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
641 struttura \struct{stat} quando si effettua chiamata ad una delle funzioni
642 \texttt{*stat} viste in sez.~\ref{sec:file_stat}.
644 Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
645 la dimensione di un file sarà più o meno corrispondente alla quantità di
646 spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
647 sposta in una posizione oltre la fine corrente del file, o come quello
648 accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
649 di un file con una \func{truncate}, in cui in sostanza di modifica il valore
650 della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
651 consente di creare inizialmente file di dimensioni anche molto grandi, senza
652 dover occupare da subito dello spazio disco che in realtà sarebbe
655 \itindend{sparse~file}
658 \subsection{Le funzioni per la lettura}
659 \label{sec:file_read}
661 Una volta che un file è stato aperto (con il permesso in lettura) si possono
662 leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
664 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
666 Cerca di leggere \param{count} byte dal file \param{fd} al buffer
669 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
670 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
672 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
673 aver potuto leggere qualsiasi dato.
674 \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
675 era aperto il file in modalità \const{O\_NONBLOCK}.
677 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
678 \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
679 natura dell'oggetto connesso a \param{fd}.}
682 La funzione tenta di leggere \param{count} byte a partire dalla posizione
683 corrente nel file. Dopo la lettura la posizione sul file è spostata
684 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
685 funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
686 presente che non è detto che la funzione \func{read} restituisca sempre il
687 numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
688 può restituire un numero di byte inferiore; questo è un comportamento normale,
689 e non un errore, che bisogna sempre tenere presente.
691 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
692 di quanto il file ne contenga. In questo caso il file viene letto fino alla
693 sua fine, e la funzione ritorna regolarmente il numero di byte letti
694 effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
695 di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La
696 condizione di raggiungimento della fine del file non è un errore, e viene
697 segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
698 ulteriormente la lettura non avrebbe nessun effetto se non quello di
699 continuare a ricevere zero come valore di ritorno.
701 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
702 un numero di byte letti inferiore a quello richiesto, ma questo non è vero
703 quando si legge da un terminale, da una fifo o da una pipe. In tal caso
704 infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
705 non aver selezionato la modalità non bloccante, vedi
706 sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
707 di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
708 con un numero di byte inferiore a quelli richiesti.
710 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
711 come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
712 di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
713 singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
714 dati ricevuti fino al momento della lettura.
716 Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
717 \errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
718 quando la \func{read} è bloccata in attesa di dati in ingresso e viene
719 interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
720 rieseguire la funzione. Torneremo in dettaglio sull'argomento in
721 sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
722 in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
723 dati in ingresso: la funzione allora ritorna immediatamente con un errore
724 \errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
725 \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
726 \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
727 disponibili occorre provare a ripetere la lettura in un secondo tempo.
729 La funzione \func{read} è una delle system call fondamentali, esistenti fin
730 dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
731 Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
732 state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
733 l'emulazione per i vecchi kernel che non hanno la system call, è stato
734 aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
735 delle librerie la funzione non è disponibile.} (quello che viene chiamato
736 normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
737 definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
738 \begin{prototype}{unistd.h}
739 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
741 Cerca di leggere \param{count} byte dal file \param{fd}, a partire dalla
742 posizione \param{offset}, nel buffer \param{buf}.
744 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
745 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
746 visti per \func{read} e \func{lseek}.}
749 La funzione prende esattamente gli stessi argomenti di \func{read} con lo
750 stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
751 una posizione sul file. Identico è il comportamento ed il valore di
752 ritorno. La funzione serve quando si vogliono leggere dati dal file senza
753 modificare la posizione corrente.
755 L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
756 da una \func{lseek} che riporti al valore precedente la posizione corrente sul
757 file, ma permette di eseguire l'operazione atomicamente. Questo può essere
758 importante quando la posizione sul file viene condivisa da processi diversi
759 (vedi sez.~\ref{sec:file_sharing}). Il valore di
760 \param{offset} fa sempre riferimento all'inizio del file.
762 La funzione \func{pread} è disponibile anche in Linux, però diventa
763 accessibile solo attivando il supporto delle estensioni previste dalle
764 \textit{Single Unix Specification} con la definizione della macro:
766 #define _XOPEN_SOURCE 500
768 e si ricordi di definire questa macro prima dell'inclusione del file di
769 dichiarazioni \headfile{unistd.h}.
773 \subsection{Le funzioni per la scrittura}
774 \label{sec:file_write}
776 Una volta che un file è stato aperto (con il permesso in scrittura) si può
777 scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
778 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
780 Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
782 \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
783 e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
786 \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
788 \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
789 consentita dal filesystem o il limite per le dimensioni dei file del
790 processo o su una posizione oltre il massimo consentito.
791 \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
792 chiuso in lettura; in questo caso viene anche generato il segnale
793 \signal{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
794 funzione ritorna questo errore.
795 \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
796 potuto scrivere qualsiasi dato.
797 \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
798 modalità \const{O\_NONBLOCK}.
800 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
801 \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
802 dipendenti dalla natura dell'oggetto connesso a \param{fd}.}
805 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
806 a partire dalla posizione corrente nel file e sposta automaticamente la
807 posizione in avanti del numero di byte scritti. Se il file è aperto in
808 modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
809 alla fine del file. Lo standard POSIX richiede che i dati scritti siano
810 immediatamente disponibili ad una \func{read} chiamata dopo che la
811 \func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
812 non è detto che tutti i filesystem supportino questa capacità.
814 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
815 Per i file ordinari il numero di byte scritti è sempre uguale a quello
816 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
817 stesso comportamento di \func{read}.
819 Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
820 per scrivere alla posizione indicata senza modificare la posizione corrente
821 nel file, il suo prototipo è:
822 \begin{prototype}{unistd.h}
823 {ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
825 Cerca di scrivere sul file \param{fd}, a partire dalla posizione
826 \param{offset}, \param{count} byte dal buffer \param{buf}.
828 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
829 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
830 visti per \func{write} e \func{lseek}.}
832 \noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
835 \section{Caratteristiche avanzate}
836 \label{sec:file_adv_func}
838 In questa sezione approfondiremo alcune delle caratteristiche più sottili
839 della gestione file in un sistema unix-like, esaminando in dettaglio il
840 comportamento delle funzioni base, inoltre tratteremo le funzioni che
841 permettono di eseguire alcune operazioni avanzate con i file (il grosso
842 dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
845 \subsection{La condivisione dei files}
846 \label{sec:file_sharing}
848 In sez.~\ref{sec:file_fd} abbiamo descritto brevemente l'architettura
849 dell'interfaccia con i file da parte di un processo, mostrando in
850 fig.~\ref{fig:file_proc_file} le principali strutture usate dal kernel;
851 esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
852 confronti dell'accesso allo stesso file da parte di processi diversi.
856 \includegraphics[width=15cm]{img/filemultacc}
857 \caption{Schema dell'accesso allo stesso file da parte di due processi
859 \label{fig:file_mult_acc}
862 Il primo caso è quello in cui due processi diversi aprono lo stesso file su
863 disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
864 situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
865 processo avrà una sua voce nella \textit{file table} referenziata da un
866 diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
867 nella \itindex{file~table} \textit{file table} faranno però riferimento allo
868 stesso \itindex{inode} inode su disco.
870 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
871 la sua modalità di accesso e versioni proprie di tutte le proprietà che
872 vengono mantenute nella sua voce della \itindex{file~table} \textit{file
873 table}. Questo ha conseguenze specifiche sugli effetti della possibile
874 azione simultanea sullo stesso file, in particolare occorre tenere presente
877 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
878 \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
879 scrittura eccede la dimensione corrente del file questo verrà esteso
880 automaticamente con l'aggiornamento del campo \var{i\_size} \itindex{inode}
882 \item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
883 le volte che viene effettuata una scrittura la posizione corrente viene
884 prima impostata alla dimensione corrente del file letta \itindex{inode}
885 dall'inode. Dopo la scrittura il file viene automaticamente esteso.
886 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
887 \var{f\_pos} nella struttura \kstruct{file} della \itindex{file~table}
888 \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
889 si usa per porsi alla fine del file la posizione viene impostata leggendo la
890 dimensione corrente \itindex{inode} dall'inode.
895 \includegraphics[width=15cm]{img/fileshar}
896 \caption{Schema dell'accesso ai file da parte di un processo figlio}
897 \label{fig:file_acc_child}
900 Il secondo caso è quello in cui due file descriptor di due processi diversi
901 puntino alla stessa voce nella \itindex{file~table} \textit{file table};
902 questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
903 figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
904 sez.~\ref{sec:proc_fork}). La situazione è illustrata in
905 fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
906 dello spazio di indirizzi del padre, riceverà anche una copia di
907 \kstruct{file\_struct} e relativa tabella dei file aperti.
909 In questo modo padre e figlio avranno gli stessi file descriptor che faranno
910 riferimento alla stessa voce nella \textit{file table}, condividendo così la
911 posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
912 sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
913 corrente nel file varierà per entrambi i processi (in quanto verrà modificato
914 \var{f\_pos} che è lo stesso per entrambi).
916 Si noti inoltre che anche i flag di stato del file (quelli impostati
917 dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
918 \textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
919 \kstruct{file}.}, vengono in questo caso condivisi. Ai file però sono
920 associati anche altri flag, dei quali l'unico usato al momento è
921 \const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
922 tenuti invece in \kstruct{file\_struct}, e perciò sono specifici di ciascun
923 processo e non vengono modificati dalle azioni degli altri anche in caso di
924 condivisione della stessa voce della \textit{file table}.
928 \subsection{Operazioni atomiche con i file}
929 \label{sec:file_atomic}
931 Come si è visto in un sistema unix-like è sempre possibile per più processi
932 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
933 scrittura possono essere fatte da ogni processo in maniera autonoma in base
934 ad una posizione corrente nel file che è locale a ciascuno di essi.
936 Se dal punto di vista della lettura dei dati questo non comporta nessun
937 problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
938 maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
939 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
940 utilizzare meccanismi di sincronizzazione più complessi (come il
941 \itindex{file~locking} \textit{file locking}, che esamineremo in
942 sez.~\ref{sec:file_locking}).
944 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
945 vari processi devono scrivere alla fine di un file (ad esempio un file di
946 log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
947 fine del file e poi scrivere può condurre ad una \itindex{race~condition}
948 \textit{race condition}: infatti può succedere che un secondo processo scriva
949 alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
950 abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
951 ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
952 più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
955 Il problema è che usare due system call in successione non è un'operazione
956 atomica; il problema è stato risolto introducendo la modalità
957 \itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
958 descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
959 alla fine del file prima di effettuare la scrittura, e poi estende il file.
960 Tutto questo avviene all'interno di una singola system call (la \func{write})
961 che non essendo interrompibile da un altro processo costituisce un'operazione
964 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
965 creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
966 esiste. In questo caso la sequenza logica porterebbe a verificare prima
967 l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
968 di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
969 condition} da parte di un altro processo che crea lo stesso file fra il
970 controllo e la creazione.
972 Per questo motivo sono stati introdotti per \func{open} i due flag
973 \const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
974 dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
975 creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
976 di una singola system call (per i dettagli sull'uso di questa caratteristica
977 si veda sez.~\ref{sec:ipc_file_lock}).
980 \subsection{Le funzioni \func{sync} e \func{fsync}}
981 \label{sec:file_sync}
983 % TODO, aggiungere syncfs, introdotta con il 2.6.39
985 Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
986 sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
987 asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
988 secondo tempo rispetto al momento della esecuzione della \func{write}.
990 Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
991 sistema mette a disposizione delle funzioni che provvedono a forzare lo
992 scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
993 questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
994 l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
995 ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
996 scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
998 \begin{prototype}{unistd.h}{int sync(void)}
1000 Sincronizza il buffer della cache dei file col disco.
1002 \bodydesc{La funzione ritorna sempre zero.}
1004 \noindent i vari standard prevedono che la funzione si limiti a far partire
1005 le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
1006 la funzione aspetta la conclusione delle operazioni di sincronizzazione del
1009 La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
1010 esplicitamente lo scarico dei dati su disco, o dal demone di sistema
1011 \cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
1012 valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
1013 in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
1014 partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
1015 tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
1016 può essere controllato attraverso il file \sysctlfile{vm/bdflush} (per
1017 il significato dei valori si può leggere la documentazione allegata al kernel
1018 in \file{Documentation/sysctl/vm.txt}).
1020 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
1021 sicuri che i dati di un database sono stati registrati su disco) si possono
1022 usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
1025 \funcdecl{int fsync(int fd)}
1026 Sincronizza dati e meta-dati del file \param{fd}
1027 \funcdecl{int fdatasync(int fd)}
1028 Sincronizza i dati del file \param{fd}.
1030 \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
1031 errore, nel qual caso \var{errno} assume i valori:
1033 \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
1034 che non supporta la sincronizzazione.
1036 ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
1039 Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
1040 file specificato, ed attendono fino alla conclusione delle operazioni;
1041 \func{fsync} forza anche la sincronizzazione dei meta-dati del file (che
1042 riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
1043 altri dati contenuti \itindex{inode} nell'inode che si leggono con \func{fstat},
1044 come i tempi del file).
1046 Si tenga presente che questo non comporta la sincronizzazione della
1047 directory che contiene il file (e scrittura della relativa voce su
1048 disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
1049 il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
1050 il kernel provvede anche alla sincronizzazione automatica delle voci
1054 \subsection{Le funzioni \func{dup} e \func{dup2}}
1055 \label{sec:file_dup}
1057 Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
1058 condivida gli stessi file descriptor del padre; è possibile però ottenere un
1059 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
1060 un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
1062 \begin{prototype}{unistd.h}{int dup(int oldfd)}
1063 Crea una copia del file descriptor \param{oldfd}.
1065 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
1066 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
1069 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
1070 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
1075 La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
1076 file descriptor è una copia esatta del precedente ed entrambi possono essere
1077 interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
1078 può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
1079 semplicemente quello di copiare il valore nella struttura
1080 \kstruct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
1081 alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
1082 file descriptor è \textsl{duplicato}, da cui il nome della funzione.
1084 \begin{figure}[!htb]
1085 \centering \includegraphics[width=14cm]{img/filedup}
1086 \caption{Schema dell'accesso ai file duplicati}
1087 \label{fig:file_dup}
1090 Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
1091 duplicati condivideranno eventuali lock, \textit{file status flag}, e
1092 posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
1093 posizione su uno dei due file descriptor, essa risulterà modificata anche
1094 sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
1095 della \textit{file table} a cui entrambi fanno riferimento). L'unica
1096 differenza fra due file descriptor duplicati è che ciascuno avrà il suo
1097 \textit{file descriptor flag}; a questo proposito va specificato che nel caso
1098 di \func{dup} il flag di \textit{close-on-exec} \itindex{close-on-exec} (vedi
1099 sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
1102 L'uso principale di questa funzione è per la redirezione dell'input e
1103 dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
1104 diventa così possibile associare un file (o una pipe) allo standard input o
1105 allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
1106 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
1107 il file che si vuole sostituire, cosicché il suo file descriptor possa esser
1108 restituito alla chiamata di \func{dup}, come primo file descriptor
1111 Dato che questa è l'operazione più comune, è prevista una diversa versione
1112 della funzione, \funcd{dup2}, che permette di specificare esplicitamente
1113 qual è il valore di file descriptor che si vuole avere come duplicato; il suo
1115 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
1117 Rende \param{newfd} una copia del file descriptor \param{oldfd}.
1119 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
1120 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1122 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
1123 un valore fuori dall'intervallo consentito per i file descriptor.
1124 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
1128 \noindent e qualora il file descriptor \param{newfd} sia già aperto (come
1129 avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
1130 sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
1131 allo stesso valore per il file descriptor).
1133 La duplicazione dei file descriptor può essere effettuata anche usando la
1134 funzione di controllo dei file \func{fcntl} (che esamineremo in
1135 sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
1136 la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
1137 \param{newfd} diventa equivalente a \func{dup}.
1139 La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
1140 diversi codici di errore.} è che \func{dup2} chiude il file descriptor
1141 \param{newfd} se questo è già aperto, garantendo che la duplicazione sia
1142 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
1143 file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
1144 \param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
1148 \subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
1149 \label{sec:file_openat}
1151 \itindbeg{at-functions}
1153 Un problema che si pone con l'uso della funzione \func{open}, così come per
1154 molte altre funzioni che accettano come argomenti dei
1155 \itindsub{pathname}{relativo} \textit{pathname} relativi, è che, quando un
1156 \textit{pathname} relativo non fa riferimento alla \index{directory~di~lavoro}
1157 directory di lavoro corrente, è possibile che alcuni dei suoi componenti
1158 vengano modificati in parallelo alla chiamata a \func{open}, e questo lascia
1159 aperta la possibilità di una \itindex{race~condition} \textit{race condition}.
1161 Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
1162 corrente è una proprietà del singolo processo; questo significa che quando si
1163 lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
1164 ma esistono molti casi in cui sarebbe invece utile che ogni singolo
1165 \itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
1166 directory di lavoro.
1168 Per risolvere questi problemi, riprendendo una interfaccia già presente in
1169 Solaris, a fianco delle normali funzioni che operano sui file (come
1170 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
1171 funzioni, dette anche funzioni ``\textit{at}'' in quanto contraddistinte dal
1172 suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
1173 altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
1174 relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
1175 proposta dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
1176 corrispondenti system call sono state inserite nel kernel ufficiale a
1177 partire dalla versione 2.6.16, in precedenza era disponibile una emulazione
1178 che, sia pure con prestazioni inferiori, funzionava facendo ricorso all'uso
1179 del filesystem \textit{proc} con l'apertura del file attraverso il
1180 riferimento a \textit{pathname} del tipo di
1181 \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
1182 siano presenti negli standard tradizionali esse sono state adottate da vari
1183 Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
1184 essere incluse nella recente revisione (la POSIX.1-2008) dello standard
1185 POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
1186 definire la macro \macro{\_ATFILE\_SOURCE}.
1188 L'uso di queste funzioni prevede una apertura iniziale della directory che
1189 sarà la base della risoluzione dei \itindsub{pathname}{relativo}
1190 \textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
1191 passare il relativo file descriptor alle varie funzioni che useranno quella
1192 directory come punto di partenza per la risoluzione.\footnote{in questo modo,
1193 anche quando si lavora con i \itindex{thread} \textit{thread}, si può
1194 mantenere una \index{directory~di~lavoro} directory di lavoro diversa per
1197 Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
1198 \textit{race condition}, consente anche di ottenere aumenti di prestazioni
1199 significativi quando si devono eseguire molte operazioni su sezioni
1200 dell'albero dei file che prevedono delle gerarchie di sottodirectory molto
1201 profonde; infatti in questo caso basta eseguire la risoluzione del
1202 \textit{pathname} della directory di partenza una sola volta (nell'apertura
1203 iniziale) e non tutte le volte che si deve accedere a ciascun file che essa
1206 La sintassi generale di queste nuove funzioni è che esse prevedono come primo
1207 argomento il file descriptor della directory da usare come base, mentre gli
1208 argomenti successivi restano identici a quelli della corrispondente funzione
1209 ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
1213 \funcdecl{int openat(int dirfd, const char *pathname, int flags)}
1214 \funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
1217 Apre un file usando come directory di \index{directory~di~lavoro} lavoro
1218 corrente \param{dirfd}.
1220 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1221 errore di \func{open}, ed in più:
1223 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1224 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1225 \textit{pathname} relativo, ma
1226 \param{dirfd} fa riferimento ad un file.
1230 Il comportamento delle nuove funzioni è del tutto analogo a quello delle
1231 corrispettive classiche, con la sola eccezione del fatto che se fra i loro
1232 argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
1233 relativo questo sarà risolto rispetto alla directory indicata
1234 da \param{dirfd}; qualora invece si usi un \itindsub{pathname}{assoluto}
1235 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
1237 \param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
1238 come le altre costanti \texttt{AT\_*}, è definita in \headfile{fcntl.h},
1239 pertanto se la si vuole usare occorrerà includere comunque questo file,
1240 anche per le funzioni che non sono definite in esso.} la risoluzione sarà
1241 effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
1242 corrente del processo.
1244 Così come il comportamento, anche i valori di ritorno e le condizioni di
1245 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
1246 errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
1247 particolare si avrà un errore di \errcode{EBADF} se esso non è un file
1248 descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
1249 riferimento ad una directory.\footnote{tranne il caso in cui si sia
1250 specificato un \itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel
1251 qual caso, come detto, il valore di \param{dirfd} sarà completamente
1254 In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
1255 con questa nuova interfaccia, con a fianco la corrispondente funzione
1256 classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
1257 funzioni \func{utimes} e \func{lutimes} non sono propriamente le
1258 corrispondenti di \func{utimensat}, dato che questa ha una maggiore
1259 precisione nella indicazione dei tempi dei file.} La gran parte di queste
1260 seguono la convenzione appena vista per \func{openat}, in cui agli argomenti
1261 della corrispondente funzione classica viene anteposto
1262 l'argomento \param{dirfd}.\footnote{non staremo pertanto a riportarle una per
1263 una.} Per una parte di queste, indicate dal contenuto della omonima colonna
1264 di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
1265 prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
1270 \begin{tabular}[c]{|l|c|l|}
1272 \textbf{Funzione} &\textbf{Flags} &\textbf{Corrispondente} \\
1275 \func{faccessat} &$\bullet$&\func{access} \\
1276 \func{fchmodat} &$\bullet$&\func{chmod} \\
1277 \func{fchownat} &$\bullet$&\func{chown},\func{lchown}\\
1278 \func{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
1279 \func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
1280 \func{linkat} &$\bullet$\footnotemark&\func{link} \\
1281 \funcm{mkdirat} & -- &\func{mkdir} \\
1282 \funcm{mknodat} & -- &\func{mknod} \\
1283 \func{openat} & -- &\func{open} \\
1284 \funcm{readlinkat}& -- &\func{readlink}\\
1285 \funcm{renameat} & -- &\func{rename} \\
1286 \funcm{symlinkat}& -- &\func{symlink} \\
1287 \func{unlinkat} &$\bullet$&\func{unlink},\func{rmdir} \\
1288 \funcm{mkfifoat} & -- &\func{mkfifo} \\
1291 \caption{Corrispondenze fra le nuove funzioni ``\textit{at}'' e le
1292 corrispettive funzioni classiche.}
1293 \label{tab:file_atfunc_corr}
1296 \footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
1297 utilizzabile solo a partire dal kernel 2.6.18.}
1299 % TODO manca prototipo di fchmodat, verificare se metterlo o metter menzione
1300 % TODO manca prototipo di fstatat, verificare se metterlo o metter menzione
1301 % TODO manca prototipo di linkat, verificare se metterlo o metter menzione
1302 % TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
1304 Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
1305 \funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
1306 un meccanismo con cui modificarne il comportamento nel caso si stia operando
1307 su un link simbolico, così da poter scegliere se far agire la funzione
1308 direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
1309 casi esso può fornire ulteriori indicazioni per modificare il comportamento
1310 delle funzioni, \param{flags} deve comunque essere passato come maschera
1311 binaria, ed impostato usando i valori delle appropriate costanti
1312 \texttt{AT\_*}, definite in \headfile{fcntl.h}.
1314 Come esempio di questo secondo tipo di funzioni possiamo considerare
1315 \funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
1316 che \func{lchown}; il suo prototipo è:
1318 \headdecl{unistd.h} \headdecl{fcntl.h}
1320 \funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
1323 Modifica la proprietà di un file.
1325 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1326 errore di \func{chown}, ed in più:
1328 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1329 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1330 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1331 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1335 In questo caso il valore di \param{flags} stabilisce il comportamento della
1336 funzione quando la si applica ad un link simbolico, e l'unico valore
1337 utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è
1338 definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
1339 link simbolici, essendo questo però il comportamento adottato per un valore
1340 nullo di \param{flags} questo valore non viene mai usato.} che se impostato
1341 indica alla funzione di non eseguire la dereferenziazione di un eventuale link
1342 simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che
1345 Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
1346 solo due funzioni possono usare l'argomento \param{flags} con valori diversi
1347 da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
1351 \funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
1353 Controlla i permessi di accesso.
1355 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1356 errore di \func{access}, ed in più:
1358 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1359 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1360 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1361 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1365 La funzione esegue lo stesso controllo di accesso effettuabile con
1366 \func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
1367 il comportamento rispetto a quello ordinario di \func{access}. In questo caso
1368 esso può essere specificato come maschera binaria di due valori:
1369 \begin{basedescript}{\desclabelwidth{3.0cm}}
1370 \item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
1371 dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
1372 comportamento di default, che riprende quello di \func{access}).
1373 \item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
1374 la dereferenziazione dei link simbolici, effettuando il controllo dei
1375 permessi direttamente sugli stessi.
1378 La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
1379 argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
1380 comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
1384 \funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
1386 Rimuove una voce da una directory.
1388 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1389 errore di \func{unlink} o di \func{rmdir} a seconda del valore di
1390 \param{flags}, ed in più:
1392 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1393 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1394 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1395 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1399 Di default il comportamento di \func{unlinkat} è equivalente a quello che
1400 avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
1401 in cui questo è una directory, se però si imposta \param{flags} al valore di
1402 \const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
1403 essendo questo l'unico flag disponibile per questa funzione, lo si può
1404 assegnare direttamente.} essa si comporterà come \func{rmdir}, in tal
1405 caso \param{pathname} deve essere una directory, che sarà rimossa qualora
1408 \itindend{at-functions}
1411 % TODO manca prototipo e motivazione di fexecve, da trattare qui in quanto
1412 % inserita nello stesso standard e da usare con openat, vedi
1413 % http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
1418 \subsection{La funzione \func{fcntl}}
1419 \label{sec:file_fcntl}
1421 Oltre alle operazioni base esaminate in sez.~\ref{sec:file_unix_interface}
1422 esistono tutta una serie di operazioni ausiliarie che è possibile eseguire su
1423 un file descriptor, che non riguardano la normale lettura e scrittura di dati,
1424 ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori
1425 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
1426 gestiscono con questa funzione varie modalità di I/O asincrono (vedi
1427 sez.~\ref{sec:file_asyncronous_operation}) e il \itindex{file~locking}
1428 \textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
1430 Per queste operazioni di manipolazione e di controllo delle varie proprietà e
1431 caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
1436 \funcdecl{int fcntl(int fd, int cmd)}
1437 \funcdecl{int fcntl(int fd, int cmd, long arg)}
1438 \funcdecl{int fcntl(int fd, int cmd, struct flock * lock)}
1439 Esegue una delle possibili operazioni specificate da \param{cmd}
1440 sul file \param{fd}.
1442 \bodydesc{La funzione ha valori di ritorno diversi a seconda
1443 dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
1444 il codice dell'errore è restituito nella variabile \var{errno}; i codici
1445 possibili dipendono dal tipo di operazione, l'unico valido in generale è:
1447 \item[\errcode{EBADF}] \param{fd} non è un file aperto.
1452 Il primo argomento della funzione è sempre il numero di file descriptor
1453 \var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
1454 numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
1455 sono determinati dal valore dell'argomento \param{cmd} che in sostanza
1456 corrisponde all'esecuzione di un determinato \textsl{comando}; in
1457 sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
1458 per la duplicazione dei file descriptor, una lista di tutti i possibili valori
1459 per \var{cmd} è riportata di seguito:
1460 \begin{basedescript}{\desclabelwidth{2.0cm}}
1461 \item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
1462 maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
1463 nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
1464 errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
1465 del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
1466 massimo numero di descrittori consentito.
1467 \item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
1468 valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
1469 \itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
1470 \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
1471 esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
1472 valore nullo in caso di successo e $-1$ in caso di errore.
1473 \item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
1474 \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
1475 file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
1476 (il comportamento predefinito) restano aperti.
1477 \item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
1478 caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
1479 bit impostati da \func{open} all'apertura del file che vengono memorizzati
1480 (quelli riportati nella prima e terza sezione di
1481 tab.~\ref{tab:file_open_flags}).
1482 % TODO toglire riferimeto a tabella flag e mettere altro
1484 \item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
1485 specificato da \param{arg}, ritorna un valore nullo in caso di successo o
1486 $-1$ in caso di errore. Possono essere impostati solo i bit riportati nella
1487 terza sezione di tab.~\ref{tab:file_open_flags}.\footnote{la pagina di
1488 manuale riporta come impostabili solo \const{O\_APPEND},
1489 \const{O\_NONBLOCK} e \const{O\_ASYNC}.}
1490 % TODO toglire riferimeto a tabella flag e mettere altro
1492 \item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
1493 \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
1494 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
1495 funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
1496 \item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
1497 specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
1498 qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
1499 \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
1500 nullo. Questa funzionalità è trattata in dettaglio in
1501 sez.~\ref{sec:file_posix_lock}.
1502 \item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
1503 la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
1504 l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
1505 imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
1506 nullo. Questa funzionalità è trattata in dettaglio in
1507 sez.~\ref{sec:file_posix_lock}.
1508 \item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o
1509 l'identificatore del \itindex{process~group} \textit{process
1510 group}\footnote{i \itindex{process~group} \textit{process group} sono
1511 (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
1512 controllo di sessione; a ciascuno di essi è associato un identificatore
1513 (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione
1514 dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo
1515 impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
1516 descriptor \param{fd}\footnote{il segnale viene usato sia per il
1517 \textit{Signal Drive I/O}, che tratteremo in
1518 sez.~\ref{sec:file_asyncronous_operation}, e dai vari meccanismi di
1519 notifica asincrona, che tratteremo in
1520 sez.~\ref{sec:file_asyncronous_lease}.} e \signal{SIGURG} per la notifica
1521 dei dati urgenti di un socket.\footnote{vedi
1522 sez.~\ref{sec:TCP_urgent_data}.} Nel caso di un \textit{process group}
1523 viene restituito un valore negativo il cui valore assoluto corrisponde
1524 all'identificatore del \itindex{process~group} \textit{process group}. In
1525 caso di errore viene restituito $-1$.
1526 \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
1527 l'identificatore del processo o del \itindex{process~group} \textit{process
1528 group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
1529 eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
1530 caso di successo o $-1$ in caso di errore. Come per \const{F\_GETOWN}, per
1531 impostare un \itindex{process~group} \textit{process group} si deve usare
1532 per \param{arg} un valore negativo, il cui valore assoluto corrisponde
1533 all'identificatore del \itindex{process~group} \textit{process group}.
1534 \item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
1535 sono dati disponibili in ingresso su un file descriptor aperto ed impostato
1536 per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
1537 indica il valore predefinito (che è \signal{SIGIO}), un valore diverso da
1538 zero indica il segnale richiesto, (che può essere anche lo stesso
1539 \signal{SIGIO}). In caso di errore ritorna $-1$.
1540 \item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
1541 possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
1542 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
1543 valore zero indica di usare il segnale predefinito, \signal{SIGIO}. Un altro
1544 valore diverso da zero (compreso lo stesso \signal{SIGIO}) specifica il
1545 segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
1546 installato il gestore del segnale come \var{sa\_sigaction} usando
1547 \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
1548 disponibili al gestore informazioni ulteriori riguardo il file che ha
1549 generato il segnale attraverso i valori restituiti in \struct{siginfo\_t}
1550 (come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
1551 \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
1553 \item[\const{F\_SETLEASE}] imposta o rimuove un \itindex{file~lease}
1554 \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
1555 Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
1556 processo che detiene un \textit{lease} su un file riceve una notifica
1557 qualora un altro processo cerca di eseguire una \func{open} o una
1558 \func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
1559 valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
1560 valore nullo in caso di successo o $-1$ in caso di errore. Questa
1561 funzionalità avanzata è trattata in dettaglio in
1562 sez.~\ref{sec:file_asyncronous_lease}.
1563 \item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
1564 \textit{file lease} che il processo detiene nei confronti del file
1565 descriptor \var{fd} o $-1$ in caso di errore. Con questo comando il terzo
1566 argomento può essere omesso. Questa funzionalità avanzata è trattata in
1567 dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
1568 \item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
1569 riportata al processo chiamante, tramite il segnale \signal{SIGIO} (o altro
1570 segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
1571 direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
1572 in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
1573 di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
1574 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
1577 La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
1578 poter essere affrontate in tutti i loro aspetti a questo punto; saranno
1579 pertanto riprese più avanti quando affronteremo le problematiche ad esse
1580 relative. In particolare le tematiche relative all'I/O asincrono e ai vari
1581 meccanismi di notifica saranno trattate in maniera esaustiva in
1582 sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
1583 \itindex{file~locking} \textit{file locking} saranno esaminate in
1584 sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
1585 trattato in sez.~\ref{sec:sock_ctrl_func}.
1587 Si tenga presente infine che quando si usa la funzione per determinare le
1588 modalità di accesso con cui è stato aperto il file (attraverso l'uso del
1589 comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
1590 \textit{file status flag} che si è ottenuto. Infatti la definizione corrente
1591 di quest'ultimo non assegna bit separati alle tre diverse modalità
1592 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
1593 queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
1594 motivo il valore della modalità di accesso corrente si ottiene eseguendo un
1595 AND binario del valore di ritorno di \func{fcntl} con la maschera
1596 \const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
1597 bit di accesso dal \textit{file status flag}.
1601 \subsection{La funzione \func{ioctl}}
1602 \label{sec:file_ioctl}
1604 Benché il concetto di \textit{everything is a file} si sia dimostrato molto
1605 valido anche per l'interazione con i dispositivi più vari, fornendo una
1606 interfaccia che permette di interagire con essi tramite le stesse funzioni
1607 usate per i normali file di dati, esisteranno sempre caratteristiche
1608 peculiari, specifiche dell'hardware e della funzionalità che ciascun
1609 dispositivo può provvedere, che non possono venire comprese in questa
1610 interfaccia astratta (un caso tipico è l'impostazione della velocità di una
1611 porta seriale, o le dimensioni di un framebuffer).
1613 Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
1614 di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
1615 specifiche di ogni dispositivo particolare, usando come riferimento il solito
1616 file descriptor. Il prototipo di questa funzione è:
1617 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
1619 Esegue l'operazione di controllo specificata da \param{request} sul file
1620 descriptor \param{fd}.
1622 \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
1623 operazioni usano però il valore di ritorno per restituire informazioni. In
1624 caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
1627 \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
1628 dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
1629 riferimento \param{fd}.
1630 \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
1633 ed inoltre \errval{EBADF} e \errval{EFAULT}.}
1636 La funzione serve in sostanza come meccanismo generico per fare tutte quelle
1637 operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
1638 file e che non è possibile effettuare con le funzioni esaminate finora. La
1639 funzione richiede che si passi come primo argomento un file descriptor
1640 regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
1641 il valore dell'argomento \param{request}. Il terzo argomento dipende
1642 dall'operazione prescelta; tradizionalmente è specificato come \code{char *
1643 argp}, da intendersi come puntatore ad un area di memoria
1644 generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
1645 non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
1646 essere omesso, e per altre è un semplice intero.
1648 Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
1649 errore, ma per alcune operazione il valore di ritorno, che nel caso viene
1650 impostato ad un valore positivo, può essere utilizzato come parametro di
1651 uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
1654 Data la genericità dell'interfaccia non è possibile classificare in maniera
1655 sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
1656 elenco di alcuni esempi di esse è il seguente:
1658 \item il cambiamento dei font di un terminale.
1659 \item l'esecuzione di una traccia audio di un CDROM.
1660 \item i comandi di avanti veloce e riavvolgimento di un nastro.
1661 \item il comando di espulsione di un dispositivo rimovibile.
1662 \item l'impostazione della velocità trasmissione di una linea seriale.
1663 \item l'impostazione della frequenza e della durata dei suoni emessi dallo
1665 \item l'impostazione degli attributi dei file su un filesystem
1666 ext2.\footnote{i comandi \texttt{lsattr} e \texttt{chattr} fanno questo con
1667 delle \func{ioctl} dedicate, usabili solo su questo filesystem e derivati
1668 successivi (come ext3).}
1671 In generale ogni dispositivo ha un suo insieme di operazioni specifiche
1672 effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
1673 file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
1674 fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
1675 opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
1676 un apposito \textit{magic number} per distinguere ciascun dispositivo nella
1677 definizione delle macro da usare per \param{request}, in modo da essere
1678 sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
1679 causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
1680 una trattazione dettagliata dell'argomento.} così che la richiesta di
1681 operazioni relative ad altri dispositivi usualmente provoca il ritorno della
1682 funzione con una condizione di errore, in alcuni casi, relativi a valori
1683 assegnati prima che questa differenziazione diventasse pratica corrente, si
1684 potrebbero usare valori validi anche per il dispositivo corrente, con effetti
1685 imprevedibili o indesiderati.
1687 Data la assoluta specificità della funzione, il cui comportamento varia da
1688 dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
1689 sommaria delle sue caratteristiche; torneremo ad esaminare in
1690 seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
1691 sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
1692 esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
1693 quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
1694 operazioni che sono predefinite per qualunque file,\footnote{in particolare
1695 queste operazioni sono definite nel kernel a livello generale, e vengono
1696 sempre interpretate per prime, per cui, come illustrato in \cite{LinDevDri},
1697 eventuali operazioni specifiche che usino lo stesso valore verrebbero
1698 ignorate.} caratterizzate dal prefisso \texttt{FIO}:
1699 \begin{basedescript}{\desclabelwidth{2.0cm}}
1700 \item[\const{FIOCLEX}] imposta il flag di \itindex{close-on-exec}
1701 \textit{close-on-exec} sul file, in questo caso, essendo usata come
1702 operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
1703 eventuale valore viene ignorato.
1704 \item[\const{FIONCLEX}] cancella il flag di \itindex{close-on-exec}
1705 \textit{close-on-exec} sul file, in questo caso, essendo usata come
1706 operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
1707 eventuale valore viene ignorato.
1708 \item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
1709 file (vedi sez.~\ref{sec:file_asyncronous_operation}); il terzo argomento
1710 deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
1711 che contiene un valore logico (un valore nullo disabilita, un valore non
1713 \item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
1714 bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
1715 tipo \texttt{const int *}) che contiene un valore logico (un valore nullo
1716 disabilita, un valore non nullo abilita).
1717 \item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
1718 \signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
1719 essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
1720 valore specifica il PID del processo.
1721 \item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
1722 \signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
1723 essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
1724 scritto il PID del processo.
1725 \item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
1726 file descriptor;\footnote{questa operazione è disponibile solo su alcuni
1727 file descriptor, in particolare sui socket (vedi
1728 sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
1729 (vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
1730 puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
1732 \item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
1733 directory, mentre se applicata ad un dispositivo fallisce con un errore di
1734 \errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
1735 (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
1738 % TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
1740 Si noti però come la gran parte di queste operazioni specifiche dei file (per
1741 essere precisi le prime sei dell'elenco) siano effettuabili in maniera
1742 generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
1743 molto simili e la presenza di questa sovrapposizione è principalmente dovuta
1744 al fatto che alle origini di Unix i progettisti considerarono che era
1745 necessario trattare diversamente rispetto alle operazione di controllo delle
1746 modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
1747 \func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
1748 usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
1749 l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
1750 ma le due funzioni sono rimaste.
1752 % TODO trovare qualche posto per la eventuale documentazione delle seguenti
1753 % (bassa/bassissima priorità)
1754 % EXT4_IOC_MOVE_EXT (dal 2.6.31)
1761 \section{L'interfaccia standard ANSI C}
1762 \label{sec:files_std_interface}
1765 Come visto in sez.~\ref{sec:file_unix_interface} le operazioni di I/O sui file
1766 sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
1767 direttamente alle \textit{system call} messe a disposizione dal kernel.
1769 Questa interfaccia però non provvede le funzionalità previste dallo standard
1770 ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
1771 queste, insieme alle altre funzioni definite dallo standard, vengono a
1772 costituire il nucleo\footnote{queste funzioni sono state implementate la prima
1773 volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente
1774 immutate.} delle \acr{glibc}.
1777 Esamineremo in questa sezione le funzioni base dell'interfaccia degli
1778 \textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
1779 file descriptor. In particolare vedremo come aprire, leggere, scrivere e
1780 cambiare la posizione corrente in uno \textit{stream}.
1783 \subsection{I \textit{file stream}}
1784 \label{sec:file_stream}
1786 \itindbeg{file~stream}
1788 Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
1789 basso livello, che non provvede nessuna forma di formattazione dei dati e
1790 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
1792 In \cite{APUE} Stevens descrive una serie di test sull'influenza delle
1793 dimensioni del blocco di dati (l'argomento \param{buf} di \func{read} e
1794 \func{write}) nell'efficienza nelle operazioni di I/O con i file descriptor,
1795 evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni
1796 del buffer dei dati pari a quelle dei blocchi del filesystem (il valore dato
1797 dal campo \var{st\_blksize} di \struct{stat}), che di norma corrispondono alle
1798 dimensioni dei settori fisici in cui è suddiviso il disco.
1800 Se il programmatore non si cura di effettuare le operazioni in blocchi di
1801 dimensioni adeguate, le prestazioni sono inferiori. La caratteristica
1802 principale dell'interfaccia degli \textit{stream} è che essa provvede da sola
1803 alla gestione dei dettagli della bufferizzazione e all'esecuzione delle
1804 operazioni di lettura e scrittura in blocchi di dimensioni appropriate
1805 all'ottenimento della massima efficienza.
1807 Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
1808 \textit{file stream}, dato che non è più necessario doversi preoccupare
1809 dei dettagli della comunicazione con il tipo di hardware sottostante
1810 (come nel caso della dimensione dei blocchi del filesystem), ed un file
1811 può essere sempre considerato come composto da un flusso continuo (da
1812 cui il nome \textit{stream}) di dati.
1814 A parte i dettagli legati alla gestione delle operazioni di lettura e
1815 scrittura (sia per quel che riguarda la bufferizzazione, che le
1816 formattazioni), i \textit{file stream} restano del tutto equivalenti ai file
1817 descriptor (sui quali sono basati), ed in particolare continua a valere quanto
1818 visto in sez.~\ref{sec:file_sharing} a proposito dell'accesso condiviso ed in
1819 sez.~\ref{sec:file_access_control} per il controllo di accesso.
1821 \itindend{file~stream}
1824 \subsection{Gli oggetti \type{FILE}}
1825 \label{sec:file_FILE}
1828 Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
1829 è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
1830 libreria e contengono tutte le informazioni necessarie a gestire le operazioni
1831 sugli \textit{stream}, come la posizione corrente, lo stato del buffer e degli
1832 indicatori di stato e di fine del file.
1834 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
1835 queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
1836 usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa
1837 (tanto che in certi casi il termine di puntatore a file è diventato sinonimo
1838 di \textit{stream}). Tutte le funzioni della libreria che operano sui file
1839 accettano come argomenti solo variabili di questo tipo, che diventa
1840 accessibile includendo l'header file \headfile{stdio.h}.
1843 \subsection{Gli \textit{stream standard}}
1844 \label{sec:file_std_stream}
1846 Ai tre file descriptor standard (vedi tab.~\ref{tab:file_std_files}) aperti
1847 per ogni processo, corrispondono altrettanti \textit{stream}, che
1848 rappresentano i canali standard di input/output prestabiliti; anche questi tre
1849 \textit{stream} sono identificabili attraverso dei nomi simbolici definiti
1850 nell'header \headfile{stdio.h} che sono:
1852 \begin{basedescript}{\desclabelwidth{3.0cm}}
1853 \item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
1854 stream} da cui il processo riceve ordinariamente i dati in
1855 ingresso. Normalmente è associato dalla shell all'input del terminale e
1856 prende i caratteri dalla tastiera.
1857 \item[\var{FILE *stdout}] Lo \textit{standard output} cioè il \textit{file
1858 stream} su cui il processo invia ordinariamente i dati in
1859 uscita. Normalmente è associato dalla shell all'output del terminale e
1860 scrive sullo schermo.
1861 \item[\var{FILE *stderr}] Lo \textit{standard error} cioè il \textit{file
1862 stream} su cui il processo è supposto inviare i messaggi di
1863 errore. Normalmente anch'esso è associato dalla shell all'output del
1864 terminale e scrive sullo schermo.
1867 Nella \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
1868 tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
1869 tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
1870 programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
1871 in altri sistemi queste variabili possono essere definite da macro, e se si
1872 hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
1873 usare la funzione \func{freopen}.
1876 \subsection{Le modalità di bufferizzazione}
1877 \label{sec:file_buffering}
1879 La bufferizzazione è una delle caratteristiche principali dell'interfaccia
1880 degli \textit{stream}; lo scopo è quello di ridurre al minimo il numero di
1881 system call (\func{read} o \func{write}) eseguite nelle operazioni di
1882 input/output. Questa funzionalità è assicurata automaticamente dalla libreria,
1883 ma costituisce anche uno degli aspetti più comunemente fraintesi, in
1884 particolare per quello che riguarda l'aspetto della scrittura dei dati sul
1887 I caratteri che vengono scritti su di uno \textit{stream} normalmente vengono
1888 accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione
1889 viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
1890 inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
1891 maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene
1892 anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
1893 sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
1894 inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura
1895 invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da
1896 parte di un altro processo) si potranno vedere solo le parti effettivamente
1897 scritte, e non quelle ancora presenti nel buffer.
1899 Per lo stesso motivo, in tutte le situazioni in cui si sta facendo
1900 dell'input/output interattivo, bisognerà tenere presente le caratteristiche
1901 delle operazioni di scaricamento dei dati, poiché non è detto che ad una
1902 scrittura sullo \textit{stream} corrisponda una immediata scrittura sul
1903 dispositivo (la cosa è particolarmente evidente quando con le operazioni di
1904 input/output su terminale).
1906 Per rispondere ad esigenze diverse, lo standard definisce tre distinte
1907 modalità in cui può essere eseguita la bufferizzazione, delle quali
1908 occorre essere ben consapevoli, specie in caso di lettura e scrittura da
1909 dispositivi interattivi:
1911 \item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
1912 caratteri vengono trasmessi direttamente al file non appena possibile
1913 (effettuando immediatamente una \func{write}).
1914 \item \textit{line buffered}: in questo caso i caratteri vengono
1915 normalmente trasmessi al file in blocco ogni volta che viene
1916 incontrato un carattere di \textit{newline} (il carattere ASCII
1918 \item \textit{fully buffered}: in questo caso i caratteri vengono
1919 trasmessi da e verso il file in blocchi di dimensione opportuna.
1922 Lo standard ANSI C specifica inoltre che lo standard output e lo
1923 standard input siano aperti in modalità \textit{fully buffered} quando
1924 non fanno riferimento ad un dispositivo interattivo, e che lo standard
1925 error non sia mai aperto in modalità \textit{fully buffered}.
1927 Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
1928 ancora più precisa, e cioè impone che lo standard error sia sempre
1929 \textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
1930 rapidamente possibile) e che standard input e standard output siano aperti in
1931 modalità \textit{line buffered} quando sono associati ad un terminale (od
1932 altro dispositivo interattivo) ed in modalità \textit{fully buffered}
1935 Il comportamento specificato per standard input e standard output vale anche
1936 per tutti i nuovi \textit{stream} aperti da un processo; la selezione comunque
1937 avviene automaticamente, e la libreria apre lo \textit{stream} nella modalità
1938 più opportuna a seconda del file o del dispositivo scelto.
1940 La modalità \textit{line buffered} è quella che necessita di maggiori
1941 chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
1942 accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
1943 alla ricezione di un carattere di \textsl{a capo} (\textit{newline}); questo
1944 non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
1945 dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
1946 anche prima che sia stato inviato un carattere di \textit{newline}.
1948 Un secondo punto da tenere presente, particolarmente quando si ha a che fare
1949 con I/O interattivo, è che quando si effettua una lettura da uno
1950 \textit{stream} che comporta l'accesso al kernel\footnote{questo vuol dire che
1951 lo \textit{stream} da cui si legge è in modalità \textit{unbuffered}.} viene
1952 anche eseguito lo scarico di tutti i buffer degli \textit{stream} in
1955 In sez.~\ref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
1956 opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
1962 \subsection{Apertura e chiusura di uno \textit{stream}}
1963 \label{sec:file_fopen}
1965 Le funzioni che si possono usare per aprire uno \textit{stream} sono solo tre:
1966 \funcd{fopen}, \funcd{fdopen} e \funcd{freopen},\footnote{\func{fopen} e
1967 \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
1968 dello standard POSIX.1.} i loro prototipi sono:
1971 \funcdecl{FILE *fopen(const char *path, const char *mode)}
1972 Apre il file specificato da \param{path}.
1973 \funcdecl{FILE *fdopen(int fildes, const char *mode)}
1974 Associa uno \textit{stream} al file descriptor \param{fildes}.
1975 \funcdecl{FILE *freopen(const char *path, const char *mode, FILE *stream)}
1976 Apre il file specificato da \param{path} associandolo allo \textit{stream}
1977 specificato da \param{stream}, se questo è già aperto prima lo chiude.
1979 \bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
1980 \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
1981 ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
1983 Gli errori pertanto possono essere quelli di \func{malloc} per tutte
1984 e tre le funzioni, quelli \func{open} per \func{fopen}, quelli di
1985 \func{fcntl} per \func{fdopen} e quelli di \func{fopen},
1986 \func{fclose} e \func{fflush} per \func{freopen}.}
1989 Normalmente la funzione che si usa per aprire uno \textit{stream} è
1990 \func{fopen}, essa apre il file specificato nella modalità specificata da
1991 \param{mode}, che è una stringa che deve iniziare con almeno uno dei valori
1992 indicati in tab.~\ref{tab:file_fopen_mode} (sono possibili varie estensioni
1993 che vedremo in seguito).
1995 L'uso più comune di \func{freopen} è per redirigere uno dei tre file
1996 standard (vedi sez.~\ref{sec:file_std_stream}): il file \param{path} viene
1997 associato a \param{stream} e se questo è uno \textit{stream} già aperto viene
1998 preventivamente chiuso.
2000 Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
2001 descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
2002 \func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
2003 usare gli \textit{stream} con file come le fifo o i socket, che non possono
2004 essere aperti con le funzioni delle librerie standard del C.
2009 \begin{tabular}[c]{|l|p{8cm}|}
2011 \textbf{Valore} & \textbf{Significato}\\
2014 \texttt{r} & Il file viene aperto, l'accesso viene posto in sola
2015 lettura, lo \textit{stream} è posizionato all'inizio del
2017 \texttt{r+}& Il file viene aperto, l'accesso viene posto in lettura e
2018 scrittura, lo \textit{stream} è posizionato all'inizio del
2021 \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
2022 creato se non esiste), l'accesso viene posto in sola
2023 scrittura, lo stream\textit{} è posizionato all'inizio del
2025 \texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
2026 creato se non esiste), l'accesso viene posto in scrittura e
2027 lettura, lo \textit{stream} è posizionato all'inizio del
2030 \texttt{a} & Il file viene aperto (o creato se non esiste) in
2031 \itindex{append~mode} \textit{append mode}, l'accesso viene
2032 posto in sola scrittura.\\
2033 \texttt{a+}& Il file viene aperto (o creato se non esiste) in
2034 \itindex{append~mode} \textit{append mode}, l'accesso viene
2035 posto in lettura e scrittura.\\
2037 \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
2038 \texttt{x} & L'apertura fallisce se il file esiste già. \\
2041 \caption{Modalità di apertura di uno \textit{stream} dello standard ANSI C
2042 che sono sempre presenti in qualunque sistema POSIX.}
2043 \label{tab:file_fopen_mode}
2046 In realtà lo standard ANSI C prevede un totale di 15 possibili valori
2047 diversi per \param{mode}, ma in tab.~\ref{tab:file_fopen_mode} si sono
2048 riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
2049 il carattere \texttt{b} (come ultimo carattere o nel mezzo agli altri per
2050 le stringhe di due caratteri) che in altri sistemi operativi serve a
2051 distinguere i file binari dai file di testo; in un sistema POSIX questa
2052 distinzione non esiste e il valore viene accettato solo per
2053 compatibilità, ma non ha alcun effetto.
2055 Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
2056 indicate dopo aver specificato il \param{mode} con uno dei valori di
2057 tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
2058 evitare di sovrascrivere un file già esistente (è analoga all'uso
2059 dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
2060 esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
2063 Un'altra estensione serve a supportare la localizzazione, quando si
2064 aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
2065 valore \verb|STRING| è considerato il nome di una codifica dei caratteri
2066 e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
2067 opportune funzioni di conversione in lettura e scrittura.
2069 Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
2070 essere compatibili con quelli con cui il file descriptor è stato aperto.
2071 Inoltre i modi \cmd{w} e \cmd{w+} non troncano il file. La posizione nello
2072 \textit{stream} viene impostata a quella corrente nel file descriptor, e le
2073 variabili di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono
2074 cancellate. Il file non viene duplicato e verrà chiuso alla chiusura dello
2077 I nuovi file saranno creati secondo quanto visto in
2078 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
2080 \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
2081 \val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
2082 il processo (si veda sez.~\ref{sec:file_perm_management}).
2084 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
2085 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
2086 richiede che ci sia un'operazione di posizionamento fra un'operazione
2087 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
2088 incontrato la fine del file), altrimenti una lettura può ritornare anche
2089 il risultato di scritture precedenti l'ultima effettuata.
2091 Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
2092 una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
2093 \func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
2094 voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
2095 usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
2096 un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
2097 sufficiente a garantire la sincronizzazione.
2099 Una volta aperto lo \textit{stream}, si può cambiare la modalità di
2100 bufferizzazione (si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non
2101 si è effettuato alcuna operazione di I/O sul file.
2103 Uno \textit{stream} viene chiuso con la funzione \funcd{fclose} il cui
2105 \begin{prototype}{stdio.h}{int fclose(FILE *stream)}
2106 Chiude lo \textit{stream} \param{stream}.
2108 \bodydesc{Restituisce 0 in caso di successo e \val{EOF} in caso di errore,
2109 nel qual caso imposta \var{errno} a \errval{EBADF} se il file descriptor
2110 indicato da \param{stream} non è valido, o uno dei valori specificati
2111 dalla sottostante funzione che è fallita (\func{close}, \func{write} o
2115 La funzione effettua lo scarico di tutti i dati presenti nei buffer di uscita
2116 e scarta tutti i dati in ingresso; se era stato allocato un buffer per lo
2117 \textit{stream} questo verrà rilasciato. La funzione effettua lo scarico solo
2118 per i dati presenti nei buffer in user space usati dalle \acr{glibc}; se si
2119 vuole essere sicuri che il kernel forzi la scrittura su disco occorrerà
2120 effettuare una \func{sync} (vedi sez.~\ref{sec:file_sync}).
2122 Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
2123 GNU implementata dalle \acr{glibc}, accessibile avendo definito
2124 \macro{\_GNU\_SOURCE}, il suo prototipo è:
2125 \begin{prototype}{stdio.h}{int fcloseall(void)}
2126 Chiude tutti gli \textit{stream}.
2128 \bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
2130 \noindent la funzione esegue lo scarico dei dati bufferizzati in uscita
2131 e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
2132 provvista solo per i casi di emergenza, quando si è verificato un errore
2133 ed il programma deve essere abortito, ma si vuole compiere qualche altra
2134 operazione dopo aver chiuso i file e prima di uscire (si ricordi quanto
2135 visto in sez.~\ref{sec:proc_conclusion}).
2138 \subsection{Lettura e scrittura su uno \textit{stream}}
2141 Una delle caratteristiche più utili dell'interfaccia degli \textit{stream} è
2142 la ricchezza delle funzioni disponibili per le operazioni di lettura e
2143 scrittura sui file. Sono infatti previste ben tre diverse modalità modalità di
2144 input/output non formattato:
2146 \item\textsl{binario} in cui legge/scrive un blocco di dati alla
2147 volta, vedi sez.~\ref{sec:file_binary_io}.
2148 \item\textsl{a caratteri} in cui si legge/scrive un carattere alla
2149 volta (con la bufferizzazione gestita automaticamente dalla libreria),
2150 vedi sez.~\ref{sec:file_char_io}.
2151 \item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
2152 dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
2154 ed inoltre la modalità di input/output formattato.
2156 A differenza dell'interfaccia dei file descriptor, con gli \textit{stream} il
2157 raggiungimento della fine del file è considerato un errore, e viene
2158 notificato come tale dai valori di uscita delle varie funzioni. Nella
2159 maggior parte dei casi questo avviene con la restituzione del valore
2160 intero (di tipo \ctyp{int}) \val{EOF}\footnote{la costante deve essere
2161 negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
2162 valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
2164 Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
2165 libreria che si appoggiano a delle system call, esse non impostano
2166 direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
2167 system call che ha riportato l'errore.
2169 Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
2170 il problema di come distinguerla da un errore effettivo; basarsi solo sul
2171 valore di ritorno della funzione e controllare il valore di \var{errno}
2172 infatti non basta, dato che quest'ultimo potrebbe essere stato impostato in
2173 una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del
2174 funzionamento di \var{errno}).
2176 Per questo motivo tutte le implementazioni delle librerie standard mantengono
2177 per ogni \textit{stream} almeno due flag all'interno dell'oggetto \type{FILE},
2178 il flag di \textit{end-of-file}, che segnala che si è raggiunta la fine del
2179 file in lettura, e quello di errore, che segnala la presenza di un qualche
2180 errore nelle operazioni di input/output; questi due flag possono essere
2181 riletti dalle funzioni \funcd{feof} e \funcd{ferror}, i cui prototipi sono:
2184 \funcdecl{int feof(FILE *stream)}
2185 Controlla il flag di end-of-file di \param{stream}.
2186 \funcdecl{int ferror(FILE *stream)}
2187 Controlla il flag di errore di \param{stream}.
2189 \bodydesc{Entrambe le funzioni ritornano un valore diverso da zero se
2190 i relativi flag sono impostati.}
2192 \noindent si tenga presente comunque che la lettura di questi flag segnala
2193 soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
2194 qualunque operazione sullo \textit{stream}, il controllo quindi deve essere
2195 effettuato ogni volta che si chiama una funzione di libreria.
2197 Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
2198 la funzione \funcd{clearerr}, il cui prototipo è:
2199 \begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
2200 Cancella i flag di errore ed \textit{end-of-file} di \param{stream}.
2202 \noindent in genere si usa questa funzione una volta che si sia identificata e
2203 corretta la causa di un errore per evitare di mantenere i flag attivi, così da
2204 poter rilevare una successiva ulteriore condizione di errore. Di questa
2205 funzione esiste una analoga \funcm{clearerr\_unlocked} che non esegue il
2206 blocco dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
2209 \subsection{Input/output binario}
2210 \label{sec:file_binary_io}
2212 La prima modalità di input/output non formattato ricalca quella della
2213 interfaccia dei file descriptor, e provvede semplicemente la scrittura e la
2214 lettura dei dati da un buffer verso un file e viceversa. In generale questa è
2215 la modalità che si usa quando si ha a che fare con dati non formattati. Le due
2216 funzioni che si usano per l'I/O binario sono \funcd{fread} ed \funcd{fwrite};
2217 i loro prototipi sono:
2221 \funcdecl{size\_t fread(void *ptr, size\_t size, size\_t nmemb, FILE
2224 \funcdecl{size\_t fwrite(const void *ptr, size\_t size, size\_t
2225 nmemb, FILE *stream)}
2227 Rispettivamente leggono e scrivono \param{nmemb} elementi di dimensione
2228 \param{size} dal buffer \param{ptr} al file \param{stream}.
2230 \bodydesc{Entrambe le funzioni ritornano il numero di elementi letti o
2231 scritti, in caso di errore o fine del file viene restituito un numero di
2232 elementi inferiore al richiesto.}
2235 In genere si usano queste funzioni quando si devono trasferire su file
2236 blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
2237 tipico è quello in cui si salva un vettore (o un certo numero dei suoi
2238 elementi) con una chiamata del tipo:
2239 \includecodesnip{listati/WriteVect.c}
2240 in questo caso devono essere specificate le dimensioni di ciascun
2241 elemento ed il numero di quelli che si vogliono scrivere. Un secondo
2242 caso è invece quello in cui si vuole trasferire su file una struttura;
2243 si avrà allora una chiamata tipo:
2244 \includecodesnip{listati/WriteStruct.c}
2245 in cui si specifica la dimensione dell'intera struttura ed un solo
2248 In realtà quello che conta nel trasferimento dei dati sono le dimensioni
2249 totali, che sono sempre pari al prodotto \code{size * nelem}; la sola
2250 differenza è che le funzioni non ritornano il numero di byte scritti,
2251 ma il numero di elementi.
2253 La funzione \func{fread} legge sempre un numero intero di elementi, se
2254 incontra la fine del file l'oggetto letto parzialmente viene scartato (lo
2255 stesso avviene in caso di errore). In questo caso la posizione dello
2256 \textit{stream} viene impostata alla fine del file (e non a quella
2257 corrispondente alla quantità di dati letti).
2259 In caso di errore (o fine del file per \func{fread}) entrambe le
2260 funzioni restituiscono il numero di oggetti effettivamente letti o
2261 scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
2262 avviene per i file descriptor, questo segnala una condizione di errore e
2263 occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
2266 Benché queste funzioni assicurino la massima efficienza per il
2267 salvataggio dei dati, i dati memorizzati attraverso di esse presentano
2268 lo svantaggio di dipendere strettamente dalla piattaforma di sviluppo
2269 usata ed in genere possono essere riletti senza problemi solo dallo
2270 stesso programma che li ha prodotti.
2272 Infatti diversi compilatori possono eseguire ottimizzazioni diverse delle
2273 strutture dati e alcuni compilatori (come il \cmd{gcc}) possono anche
2274 scegliere se ottimizzare l'occupazione di spazio, impacchettando più
2275 strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
2276 l'allineamento dei medesimi generando quindi output binari diversi. Inoltre
2277 altre incompatibilità si possono presentare quando entrano in gioco differenze
2278 di architettura hardware, come la dimensione del bus o la modalità di
2279 ordinamento dei bit o il formato delle variabili in floating point.
2281 Per questo motivo quando si usa l'input/output binario occorre sempre prendere
2282 le opportune precauzioni (in genere usare un formato di più alto livello che
2283 permetta di recuperare l'informazione completa), per assicurarsi che versioni
2284 diverse del programma siano in grado di rileggere i dati tenendo conto delle
2285 eventuali differenze.
2287 Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
2288 \funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
2289 implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
2290 applicazioni \itindex{thread} \textit{multi-thread} (si veda
2291 sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
2295 \funcdecl{size\_t fread\_unlocked(void *ptr, size\_t size, size\_t
2296 nmemb, FILE *stream)}
2298 \funcdecl{size\_t fwrite\_unlocked(const void *ptr, size\_t size,
2299 size\_t nmemb, FILE *stream)}
2301 \bodydesc{Le funzioni sono identiche alle analoghe \func{fread} e
2302 \func{fwrite} ma non acquisiscono il lock implicito sullo \textit{stream}.}
2304 \noindent entrambe le funzioni sono estensioni GNU previste solo dalle
2308 \subsection{Input/output a caratteri}
2309 \label{sec:file_char_io}
2311 La seconda modalità di input/output è quella a caratteri, in cui si
2312 trasferisce un carattere alla volta. Le funzioni per la lettura a
2313 caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, i
2314 rispettivi prototipi sono:
2318 \funcdecl{int getc(FILE *stream)} Legge un byte da \param{stream} e lo
2319 restituisce come intero. In genere è implementata come una macro.
2321 \funcdecl{int fgetc(FILE *stream)} Legge un byte da \param{stream} e lo
2322 restituisce come intero. È sempre una funzione.
2324 \funcdecl{int getchar(void)} Equivalente a \code{getc(stdin)}.
2326 \bodydesc{Tutte queste funzioni leggono un byte alla volta, che viene
2327 restituito come intero; in caso di errore o fine del file il valore
2328 di ritorno è \val{EOF}.}
2331 A parte \func{getchar}, che si usa in genere per leggere un carattere da
2332 tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
2333 differenza è che \func{getc} è ottimizzata al massimo e normalmente
2334 viene implementata con una macro, per cui occorre stare attenti a cosa
2335 le si passa come argomento, infatti \param{stream} può essere valutato
2336 più volte nell'esecuzione, e non viene passato in copia con il
2337 meccanismo visto in sez.~\ref{sec:proc_var_passing}; per questo motivo se
2338 si passa un'espressione si possono avere effetti indesiderati.
2340 Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
2341 la sua esecuzione normalmente è più lenta per via dell'overhead della
2342 chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
2343 come argomento ad un altra funzione (e non si hanno i problemi accennati in
2344 precedenza nel tipo di argomento).
2346 Le tre funzioni restituiscono tutte un \ctyp{unsigned char} convertito
2347 ad \ctyp{int} (si usa \ctyp{unsigned char} in modo da evitare
2348 l'espansione del segno). In questo modo il valore di ritorno è sempre
2349 positivo, tranne in caso di errore o fine del file.
2351 Nelle estensioni GNU che provvedono la localizzazione sono definite tre
2352 funzioni equivalenti alle precedenti, \funcd{getwc}, \funcd{fgetwc} e
2353 \funcd{getwchar}, che invece di un carattere di un byte restituiscono un
2354 carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
2360 \funcdecl{wint\_t getwc(FILE *stream)} Legge un carattere esteso da
2361 \param{stream}. In genere è implementata come una macro.
2363 \funcdecl{wint\_t fgetwc(FILE *stream)} Legge un carattere esteso da
2364 \param{stream}. È una sempre una funzione.
2366 \funcdecl{wint\_t getwchar(void)} Equivalente a \code{getwc(stdin)}.
2368 \bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
2369 caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
2372 Per scrivere un carattere si possono usare tre funzioni, analoghe alle
2373 precedenti usate per leggere: \funcd{putc}, \funcd{fputc} e \funcd{putchar}; i
2374 loro prototipi sono:
2378 \funcdecl{int putc(int c, FILE *stream)} Scrive il carattere \param{c}
2379 su \param{stream}. In genere è implementata come una macro.
2381 \funcdecl{int fputc(int c, FILE *stream)} Scrive il carattere \param{c} su
2382 \param{stream}. È una sempre una funzione.
2384 \funcdecl{int putchar(int c)} Equivalente a \code{putc(stdout)}.
2386 \bodydesc{Le funzioni scrivono sempre un carattere alla volta, il cui
2387 valore viene restituito in caso di successo; in caso di errore o
2388 fine del file il valore di ritorno è \val{EOF}.}
2391 Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
2392 come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
2393 un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
2394 caso di errore o fine del file il valore di ritorno è \val{EOF}.
2396 Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
2397 provvedono come estensione, per ciascuna delle funzioni precedenti,
2398 un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
2399 \code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
2400 il lock implicito dello \textit{stream}.
2402 Per compatibilità con SVID sono inoltre provviste anche due funzioni,
2403 \funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
2404 (cioè due byte in una volta); i loro prototipi sono:
2408 \funcdecl{int getw(FILE *stream)} Legge una parola da \param{stream}.
2409 \funcdecl{int putw(int w, FILE *stream)} Scrive la parola \param{w} su
2412 \bodydesc{Le funzioni restituiscono la parola \param{w}, o \val{EOF}
2413 in caso di errore o di fine del file.}
2416 Le funzioni leggono e scrivono una \textit{word} di due byte, usando comunque
2417 una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
2418 di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
2419 valore -1 da una condizione di errore che restituisce \val{EOF}.
2421 Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
2422 \textit{parsing} in cui si analizza il testo; in questo contesto diventa utile
2423 poter analizzare il carattere successivo da uno \textit{stream} senza estrarlo
2424 effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
2425 programma possa regolarsi avendo dato una \textsl{sbirciatina} a quello che
2428 Nel nostro caso questo tipo di comportamento può essere realizzato prima
2429 leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
2430 disponibile per una lettura successiva; la funzione che inverte la
2431 lettura si chiama \funcd{ungetc} ed il suo prototipo è:
2432 \begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
2433 Rimanda indietro il carattere \param{c}, con un cast a \ctyp{unsigned
2434 char}, sullo \textit{stream} \param{stream}.
2436 \bodydesc{La funzione ritorna \param{c} in caso di successo e
2437 \val{EOF} in caso di errore.}
2439 \noindent benché lo standard ANSI C preveda che l'operazione possa
2440 essere ripetuta per un numero arbitrario di caratteri, alle
2441 implementazioni è richiesto di garantire solo un livello; questo è
2442 quello che fa la \acr{glibc}, che richiede che avvenga un'altra
2443 operazione fra due \func{ungetc} successive.
2445 Non è necessario che il carattere che si manda indietro sia l'ultimo che
2446 si è letto, e non è necessario neanche avere letto nessun carattere
2447 prima di usare \func{ungetc}, ma di norma la funzione è intesa per
2448 essere usata per rimandare indietro l'ultimo carattere letto.
2450 Nel caso \param{c} sia un \val{EOF} la funzione non fa nulla, e
2451 restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
2452 con il risultato di una lettura alla fine del file.
2454 Se si è alla fine del file si può comunque rimandare indietro un
2455 carattere, il flag di end-of-file verrà automaticamente cancellato
2456 perché c'è un nuovo carattere disponibile che potrà essere riletto
2459 Infine si tenga presente che \func{ungetc} non altera il contenuto del
2460 file, ma opera esclusivamente sul buffer interno. Se si esegue una
2461 qualunque delle operazioni di riposizionamento (vedi
2462 sez.~\ref{sec:file_fseek}) i caratteri rimandati indietro vengono
2466 \subsection{Input/output di linea}
2467 \label{sec:file_line_io}
2469 La terza ed ultima modalità di input/output non formattato è quella di linea,
2470 in cui si legge o si scrive una riga alla volta; questa è una modalità molto
2471 usata per l'I/O da terminale, ma è anche quella che presenta le
2472 caratteristiche più controverse.
2474 Le funzioni previste dallo standard ANSI C per leggere una linea sono
2475 sostanzialmente due, \funcd{gets} e \funcd{fgets}, i cui rispettivi
2480 \funcdecl{char *gets(char *string)} Scrive su \param{string} una
2481 linea letta da \var{stdin}.
2483 \funcdecl{char *fgets(char *string, int size, FILE *stream)}
2484 Scrive su \param{string} la linea letta da \param{stream} per un
2485 massimo di \param{size} byte.
2487 \bodydesc{Le funzioni restituiscono l'indirizzo \param{string} in caso
2488 di successo o \val{NULL} in caso di errore.}
2491 Entrambe le funzioni effettuano la lettura (dal file specificato \func{fgets},
2492 dallo standard input \func{gets}) di una linea di caratteri (terminata dal
2493 carattere \textit{newline}, \verb|'\n'|, quello mappato sul tasto di ritorno a
2494 capo della tastiera), ma \func{gets} sostituisce \verb|'\n'| con uno zero,
2495 mentre \func{fgets} aggiunge uno zero dopo il \textit{newline}, che resta
2496 dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
2497 viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
2498 L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
2499 funzione infatti non controlla il numero di byte letti, per cui nel caso la
2500 stringa letta superi le dimensioni del buffer, si avrà un
2501 \itindex{buffer~overflow} \textit{buffer overflow}, con sovrascrittura della
2502 memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
2503 in dettaglio e con molta efficacia nell'ormai famoso articolo di Aleph1
2506 Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
2507 autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
2508 una stringa sufficientemente lunga ed opportunamente forgiata per
2509 sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
2510 (supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
2511 far ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere
2512 uno \textit{shell code} cioè una sezione di programma che lancia una shell).
2514 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
2515 prende in input la dimensione del buffer \param{size}, che non verrà mai
2516 ecceduta in lettura. La funzione legge fino ad un massimo di \param{size}
2517 caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
2518 comporta che la stringa possa essere al massimo di \code{size-1} caratteri. Se
2519 la linea eccede la dimensione del buffer verranno letti solo \code{size-1}
2520 caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
2521 finale; sarà possibile leggere i rimanenti caratteri in una chiamata
2524 Per la scrittura di una linea lo standard ANSI C prevede altre due
2525 funzioni, \funcd{fputs} e \funcd{puts}, analoghe a quelle di lettura, i
2526 rispettivi prototipi sono:
2530 \funcdecl{int puts(const char *string)} Scrive su \var{stdout} la
2531 linea \param{string}.
2533 \funcdecl{int fputs(const char *string, FILE *stream)} Scrive su
2534 \param{stream} la linea \param{string}.
2536 \bodydesc{Le funzioni restituiscono un valore non negativo in caso di
2537 successo o \val{EOF} in caso di errore.}
2540 Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
2541 problemi di \func{gets} ed è in genere la forma più immediata per scrivere
2542 messaggi sullo standard output; la funzione prende una stringa terminata da
2543 uno zero ed aggiunge automaticamente il ritorno a capo. La differenza con
2544 \func{fputs} (a parte la possibilità di specificare un file diverso da
2545 \var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
2546 previsto esplicitamente.
2548 Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
2549 linea esistono delle estensioni per leggere e scrivere linee di caratteri
2550 estesi, le funzioni in questione sono \funcd{fgetws} e \funcd{fputws} ed i
2551 loro prototipi sono:
2554 \funcdecl{wchar\_t *fgetws(wchar\_t *ws, int n, FILE *stream)}
2555 Legge un massimo di \param{n} caratteri estesi dal file
2556 \param{stream} al buffer \param{ws}.
2558 \funcdecl{int fputws(const wchar\_t *ws, FILE *stream)} Scrive la
2559 linea \param{ws} di caratteri estesi sul file \param{stream}.
2561 \bodydesc{Le funzioni ritornano rispettivamente \param{ws} o un numero
2562 non negativo in caso di successo e \val{NULL} o \val{EOF} in
2563 caso di errore o fine del file.}
2566 Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
2567 \func{fputs}, a parte il fatto che tutto (numero di caratteri massimo,
2568 terminatore della stringa, newline) è espresso in termini di caratteri estesi
2569 anziché di normali caratteri ASCII.
2571 Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
2572 \acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
2573 illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
2574 esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
2575 implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
2576 per le altre forma di I/O, dette funzioni hanno lo stesso nome della loro
2577 analoga normale, con l'aggiunta dell'estensione \code{\_unlocked}.
2579 Come abbiamo visto, le funzioni di lettura per l'input/output di linea
2580 previste dallo standard ANSI C presentano svariati inconvenienti. Benché
2581 \func{fgets} non abbia i gravissimi problemi di \func{gets}, può
2582 comunque dare risultati ambigui se l'input contiene degli zeri; questi
2583 infatti saranno scritti sul buffer di uscita e la stringa in output
2584 apparirà come più corta dei byte effettivamente letti. Questa è una
2585 condizione che è sempre possibile controllare (deve essere presente un
2586 newline prima della effettiva conclusione della stringa presente nel
2587 buffer), ma a costo di una complicazione ulteriore della logica del
2588 programma. Lo stesso dicasi quando si deve gestire il caso di stringa
2589 che eccede le dimensioni del buffer.
2591 Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
2592 funzioni per la gestione dell'input/output di linea, il cui uso permette di
2593 risolvere questi problemi. L'uso di queste funzioni deve essere attivato
2594 definendo la macro \macro{\_GNU\_SOURCE} prima di includere
2595 \headfile{stdio.h}. La prima delle due, \funcd{getline}, serve per leggere una
2596 linea terminata da un newline, esattamente allo stesso modo di \func{fgets},
2598 \begin{prototype}{stdio.h}
2599 {ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
2600 dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
2601 riallocandolo se necessario (l'indirizzo del buffer e la sua dimensione
2602 vengono sempre riscritte).
2604 \bodydesc{La funzione ritorna il numero di caratteri letti in caso di
2605 successo e -1 in caso di errore o di raggiungimento della fine del
2609 La funzione permette di eseguire una lettura senza doversi preoccupare della
2610 eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
2611 argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
2612 linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
2613 \func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
2614 locale); come secondo argomento la funzione vuole l'indirizzo della variabile
2615 contenente le dimensioni del buffer suddetto.
2617 Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
2618 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
2619 dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti
2620 come per entrambi gli argomenti si siano usati dei
2621 \itindex{value~result~argument} \textit{value result argument}, passando dei
2622 puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
2623 sez.~\ref{sec:proc_var_passing}).
2625 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
2626 \var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
2627 necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
2628 puntatore all'inizio del testo della linea letta. Un esempio di codice può
2630 \includecodesnip{listati/getline.c}
2631 e per evitare \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
2632 liberare \var{ptr} con una \func{free}.
2634 Il valore di ritorno della funzione indica il numero di caratteri letti
2635 dallo \textit{stream} (quindi compreso il newline, ma non lo zero di
2636 terminazione); questo permette anche di distinguere eventuali zeri letti
2637 dallo \textit{stream} da quello inserito dalla funzione per terminare la linea.
2638 Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
2639 un errore la funzione restituisce -1.
2641 La seconda estensione GNU è una generalizzazione di \func{getline} per
2642 poter usare come separatore un carattere qualsiasi, la funzione si
2643 chiama \funcd{getdelim} ed il suo prototipo è:
2644 \begin{prototype}{stdio.h}
2645 {ssize\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)}
2646 Identica a \func{getline} solo che usa \param{delim} al posto del
2647 carattere di newline come separatore di linea.
2650 Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
2651 può essere implementata da questa passando \verb|'\n'| come valore di
2655 \subsection{L'input/output formattato}
2656 \label{sec:file_formatted_io}
2658 L'ultima modalità di input/output è quella formattata, che è una delle
2659 caratteristiche più utilizzate delle librerie standard del C; in genere questa
2660 è la modalità in cui si esegue normalmente l'output su terminale poiché
2661 permette di stampare in maniera facile e veloce dati, tabelle e messaggi.
2663 L'output formattato viene eseguito con una delle 13 funzioni della famiglia
2664 \func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
2665 \funcd{sprintf}, i cui prototipi sono:
2668 \funcdecl{int printf(const char *format, ...)} Stampa su \file{stdout}
2669 gli argomenti, secondo il formato specificato da \param{format}.
2671 \funcdecl{int fprintf(FILE *stream, const char *format, ...)} Stampa
2672 su \param{stream} gli argomenti, secondo il formato specificato da
2675 \funcdecl{int sprintf(char *str, const char *format, ...)} Stampa
2676 sulla stringa \param{str} gli argomenti, secondo il formato
2677 specificato da \param{format}.
2679 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
2681 \noindent le prime due servono per stampare su file (lo standard output o
2682 quello specificato) la terza permette di stampare su una stringa, in genere
2683 l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
2684 sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
2685 dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
2686 possibili \itindex{buffer~overflow} \textit{buffer overflow}; per questo
2687 motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
2689 \begin{prototype}{stdio.h}
2690 {snprintf(char *str, size\_t size, const char *format, ...)}
2691 Identica a \func{sprintf}, ma non scrive su \param{str} più di
2692 \param{size} caratteri.
2695 La parte più complessa delle funzioni di scrittura formattata è il formato
2696 della stringa \param{format} che indica le conversioni da fare, e da cui
2697 deriva anche il numero degli argomenti che dovranno essere passati a seguire
2698 (si noti come tutte queste funzioni siano \index{funzioni!variadic}
2699 \textit{variadic}, prendendo un numero di argomenti variabile che dipende
2700 appunto da quello che si è specificato in \param{format}).
2705 \begin{tabular}[c]{|l|l|p{10cm}|}
2707 \textbf{Valore} & \textbf{Tipo} & \textbf{Significato} \\
2710 \cmd{\%d} &\ctyp{int} & Stampa un numero intero in formato decimale
2712 \cmd{\%i} &\ctyp{int} & Identico a \cmd{\%i} in output.\\
2713 \cmd{\%o} &\ctyp{unsigned int}& Stampa un numero intero come ottale.\\
2714 \cmd{\%u} &\ctyp{unsigned int}& Stampa un numero intero in formato
2715 decimale senza segno.\\
2717 \cmd{\%X} &\ctyp{unsigned int}& Stampano un intero in formato esadecimale,
2718 rispettivamente con lettere minuscole e
2720 \cmd{\%f} &\ctyp{double} & Stampa un numero in virgola mobile con la
2721 notazione a virgola fissa.\\
2723 \cmd{\%E} &\ctyp{double} & Stampano un numero in virgola mobile con la
2724 notazione esponenziale, rispettivamente con
2725 lettere minuscole e maiuscole.\\
2727 \cmd{\%G} &\ctyp{double} & Stampano un numero in virgola mobile con la
2728 notazione più appropriate delle due precedenti,
2729 rispettivamente con lettere minuscole e
2732 \cmd{\%A} &\ctyp{double} & Stampano un numero in virgola mobile in
2733 notazione esadecimale frazionaria.\\
2734 \cmd{\%c} &\ctyp{int} & Stampa un carattere singolo.\\
2735 \cmd{\%s} &\ctyp{char *} & Stampa una stringa.\\
2736 \cmd{\%p} &\ctyp{void *} & Stampa il valore di un puntatore.\\
2737 \cmd{\%n} &\ctyp{\&int} & Prende il numero di caratteri stampati finora.\\
2738 \cmd{\%\%}& & Stampa un \%.\\
2741 \caption{Valori possibili per gli specificatori di conversione in una
2742 stringa di formato di \func{printf}.}
2743 \label{tab:file_format_spec}
2746 La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
2747 vengono passati invariati all'output, e da direttive di conversione, in cui
2748 devono essere sempre presenti il carattere \texttt{\%}, che introduce la
2749 direttiva, ed uno degli specificatori di conversione (riportati in
2750 tab.~\ref{tab:file_format_spec}) che la conclude.
2755 \begin{tabular}[c]{|l|p{10cm}|}
2757 \textbf{Valore} & \textbf{Significato}\\
2760 \val{\#} & Chiede la conversione in forma alternativa. \\
2761 \val{0} & La conversione è riempita con zeri alla sinistra del valore.\\
2762 \val{-} & La conversione viene allineata a sinistra sul bordo del campo.\\
2763 \val{' '}& Mette uno spazio prima di un numero con segno di valore
2765 \val{+} & Mette sempre il segno ($+$ o $-$) prima di un numero.\\
2768 \caption{I valori dei flag per il formato di \func{printf}}
2769 \label{tab:file_format_flag}
2772 Il formato di una direttiva di conversione prevede una serie di possibili
2773 elementi opzionali oltre al \cmd{\%} e allo specificatore di conversione. In
2774 generale essa è sempre del tipo:
2777 % [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
2780 in cui tutti i valori tranne il \val{\%} e lo specificatore di conversione
2781 sono opzionali (e per questo sono indicati fra parentesi quadre); si possono
2782 usare più elementi opzionali, nel qual caso devono essere specificati in
2785 \item uno specificatore del parametro da usare (terminato da un \val{\$}),
2786 \item uno o più flag (i cui valori possibili sono riassunti in
2787 tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
2789 \item uno specificatore di larghezza (un numero decimale), eventualmente
2790 seguito (per i numeri in virgola mobile) da un specificatore di precisione
2791 (un altro numero decimale),
2792 \item uno specificatore del tipo di dato, che ne indica la dimensione (i cui
2793 valori possibili sono riassunti in tab.~\ref{tab:file_format_type}).
2797 Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di
2798 manuale di \func{printf} e nella documentazione delle \acr{glibc}.
2803 \begin{tabular}[c]{|l|p{10cm}|}
2805 \textbf{Valore} & \textbf{Significato} \\
2808 \cmd{hh} & Una conversione intera corrisponde a un \ctyp{char} con o senza
2809 segno, o il puntatore per il numero dei parametri \cmd{n} è di
2811 \cmd{h} & Una conversione intera corrisponde a uno \ctyp{short} con o
2812 senza segno, o il puntatore per il numero dei parametri \cmd{n}
2813 è di tipo \ctyp{short}.\\
2814 \cmd{l} & Una conversione intera corrisponde a un \ctyp{long} con o
2815 senza segno, o il puntatore per il numero dei parametri \cmd{n}
2816 è di tipo \ctyp{long}, o il carattere o la stringa seguenti
2817 sono in formato esteso.\\
2818 \cmd{ll} & Una conversione intera corrisponde a un \ctyp{long long} con o
2819 senza segno, o il puntatore per il numero dei parametri \cmd{n}
2820 è di tipo \ctyp{long long}.\\
2821 \cmd{L} & Una conversione in virgola mobile corrisponde a un
2823 \cmd{q} & Sinonimo di \cmd{ll}.\\
2824 \cmd{j} & Una conversione intera corrisponde a un \type{intmax\_t} o
2825 \type{uintmax\_t}.\\
2826 \cmd{z} & Una conversione intera corrisponde a un \type{size\_t} o
2828 \cmd{t} & Una conversione intera corrisponde a un \type{ptrdiff\_t}.\\
2831 \caption{Il modificatore di tipo di dato per il formato di \func{printf}}
2832 \label{tab:file_format_type}
2835 Una versione alternativa delle funzioni di output formattato, che permettono
2836 di usare il puntatore ad una lista variabile \index{funzioni!variadic} di
2837 argomenti (vedi sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf},
2838 \funcd{vfprintf} e \funcd{vsprintf}, i cui prototipi sono:
2842 \funcdecl{int vprintf(const char *format, va\_list ap)} Stampa su
2843 \var{stdout} gli argomenti della lista \param{ap}, secondo il formato
2844 specificato da \param{format}.
2846 \funcdecl{int vfprintf(FILE *stream, const char *format, va\_list ap)}
2847 Stampa su \param{stream} gli argomenti della lista \param{ap}, secondo il
2848 formato specificato da \param{format}.
2850 \funcdecl{int vsprintf(char *str, const char *format, va\_list ap)} Stampa
2851 sulla stringa \param{str} gli argomenti della lista \param{ap}, secondo il
2852 formato specificato da \param{format}.
2854 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
2856 \noindent con queste funzioni diventa possibile selezionare gli argomenti che
2857 si vogliono passare ad una funzione di stampa, passando direttamente la lista
2858 tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
2859 variabile\index{funzioni!variadic} degli argomenti dovrà essere opportunamente
2860 trattata (l'argomento è esaminato in sez.~\ref{sec:proc_variadic}), e dopo
2861 l'esecuzione della funzione l'argomento
2862 \param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
2863 \code{va\_end(ap)} ma in Linux questo non è necessario).
2865 Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
2866 \funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
2867 scritti sulla stringa di destinazione:
2868 \begin{prototype}{stdio.h}
2869 {vsnprintf(char *str, size\_t size, const char *format, va\_list ap)}
2870 Identica a \func{vsprintf}, ma non scrive su \param{str} più di
2871 \param{size} caratteri.
2873 \noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
2877 Per eliminare alla radice questi problemi, le \acr{glibc} supportano una
2878 specifica estensione GNU che alloca dinamicamente tutto lo spazio necessario;
2879 l'estensione si attiva al solito definendo \macro{\_GNU\_SOURCE}, le due
2880 funzioni sono \funcd{asprintf} e \funcd{vasprintf}, ed i rispettivi prototipi
2885 \funcdecl{int asprintf(char **strptr, const char *format, ...)} Stampa gli
2886 argomenti specificati secondo il formato specificato da \param{format} su
2887 una stringa allocata automaticamente all'indirizzo \param{*strptr}.
2889 \funcdecl{int vasprintf(char **strptr, const char *format, va\_list ap)}
2890 Stampa gli argomenti della lista \param{ap} secondo il formato specificato
2891 da \param{format} su una stringa allocata automaticamente all'indirizzo
2894 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
2897 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
2898 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
2899 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
2900 proposito dei \itindex{value~result~argument} \textit{value result argument})
2901 l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
2902 inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
2903 la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
2906 % TODO verificare se mettere prototipi di \func{dprintf} e \func{vdprintf}
2908 Infine una ulteriore estensione GNU definisce le due funzioni \funcm{dprintf} e
2909 \funcm{vdprintf}, che prendono un file descriptor al posto dello
2910 \textit{stream}. Altre estensioni permettono di scrivere con caratteri
2911 estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
2912 funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
2913 dettaglio nella documentazione delle \acr{glibc}.
2915 In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
2916 l'output formattato, l'input formattato viene eseguito con le funzioni della
2917 famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
2918 \funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono:
2920 \headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
2921 scansione di \file{stdin} cercando una corrispondenza di quanto letto con il
2922 formato dei dati specificato da \param{format}, ed effettua le relative
2923 conversione memorizzando il risultato negli argomenti seguenti.
2925 \funcdecl{int fscanf(FILE *stream, const char *format, ...)} Analoga alla
2926 precedente, ma effettua la scansione su \param{stream}.
2928 \funcdecl{int sscanf(char *str, const char *format, ...)} Analoga alle
2929 precedenti, ma effettua la scansione dalla stringa \param{str}.
2931 \bodydesc{Le funzioni ritornano il numero di elementi assegnati. Questi
2932 possono essere in numero inferiore a quelli specificati, ed anche zero.
2933 Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
2934 di errore o fine del file viene invece restituito \val{EOF}.}
2936 \noindent e come per le analoghe funzioni di scrittura esistono le relative
2937 \funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un puntatore ad
2938 una lista di argomenti.
2940 Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
2941 puntatori alle variabili che dovranno contenere le conversioni; questo è un
2942 primo elemento di disagio in quanto è molto facile dimenticarsi di questa
2945 Le funzioni leggono i caratteri dallo \textit{stream} (o dalla stringa) di
2946 input ed eseguono un confronto con quanto indicato in \param{format}, la
2947 sintassi di questo argomento è simile a quella usata per l'analogo di
2948 \func{printf}, ma ci sono varie differenze. Le funzioni di input infatti sono
2949 più orientate verso la lettura di testo libero che verso un input formattato
2950 in campi fissi. Uno spazio in \param{format} corrisponde con un numero
2951 qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
2952 virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
2953 esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
2954 si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
2957 Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
2958 eventuali caratteri diversi indicati dalla stringa di formato) effettuando le
2959 conversioni richieste; in caso la corrispondenza fallisca (o la funzione non
2960 sia in grado di effettuare una delle conversioni richieste) la scansione viene
2961 interrotta immediatamente e la funzione ritorna lasciando posizionato lo
2962 \textit{stream} al primo carattere che non corrisponde.
2964 Data la notevole complessità di uso di queste funzioni, che richiedono molta
2965 cura nella definizione delle corrette stringhe di formato e sono facilmente
2966 soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
2967 recuperare in caso di fallimento nelle corrispondenze, l'input formattato non
2968 è molto usato. In genere infatti quando si ha a che fare con un input
2969 relativamente semplice si preferisce usare l'input di linea ed effettuare
2970 scansione e conversione di quanto serve direttamente con una delle funzioni di
2971 conversione delle stringhe; se invece il formato è più complesso diventa più
2972 facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
2973 \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
2974 analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
2975 \cite{flex}.} per generare un analizzatore lessicale o il
2976 \cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
2977 parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo
2978 manuale \cite{bison}.} per generare un parser.
2981 \subsection{Posizionamento su uno \textit{stream}}
2982 \label{sec:file_fseek}
2984 Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
2985 all'interno di un file per effettuare operazioni di lettura o scrittura in un
2986 punto prestabilito; sempre che l'operazione di riposizionamento sia supportata
2987 dal file sottostante lo \textit{stream}, quando cioè si ha a che fare con
2988 quello che viene detto un file ad \textsl{accesso casuale}.\footnote{dato che
2989 in un sistema Unix esistono vari tipi di file, come le fifo ed i
2990 \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
2993 In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
2994 espressa da un intero positivo, rappresentato dal tipo \type{off\_t}, il
2995 problema è che alcune delle funzioni usate per il riposizionamento sugli
2996 \textit{stream} originano dalle prime versioni di Unix, in cui questo tipo non
2997 era ancora stato definito, e che in altri sistemi non è detto che la posizione
2998 su un file venga sempre rappresentata con il numero di caratteri dall'inizio
2999 (ad esempio in VMS può essere rappresentata come numero di record, più
3000 l'offset rispetto al record corrente).
3002 Tutto questo comporta la presenza di diverse funzioni che eseguono
3003 sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
3004 funzioni tradizionali usate per il riposizionamento della posizione in uno
3005 \textit{stream} sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
3009 \funcdecl{int fseek(FILE *stream, long offset, int whence)} Sposta la
3010 posizione nello \textit{stream} secondo quanto specificato
3011 tramite \param{offset} e \param{whence}.
3013 \funcdecl{void rewind(FILE *stream)} Riporta la posizione nello
3014 \textit{stream} all'inizio del file.
3017 L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
3018 descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
3019 particolare \param{whence} assume gli stessi valori già visti in
3020 sez.~\ref{sec:file_lseek}. La funzione restituisce 0 in caso di successo e -1
3021 in caso di errore. La funzione \func{rewind} riporta semplicemente la
3022 posizione corrente all'inizio dello \textit{stream}, ma non esattamente
3023 equivalente ad una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono
3024 cancellati anche i flag di errore e fine del file.
3026 Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
3028 \begin{prototype}{stdio.h}{long ftell(FILE *stream)}
3029 Legge la posizione attuale nello \textit{stream} \param{stream}.
3031 \bodydesc{La funzione restituisce la posizione corrente, o -1 in caso
3032 di fallimento, che può esser dovuto sia al fatto che il file non
3033 supporta il riposizionamento che al fatto che la posizione non può
3034 essere espressa con un \ctyp{long int}}
3036 \noindent la funzione restituisce la posizione come numero di byte
3037 dall'inizio dello \textit{stream}.
3039 Queste funzioni esprimono tutte la posizione nel file come un \ctyp{long int}.
3040 Dato che (ad esempio quando si usa un filesystem indicizzato a 64 bit) questo
3041 può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
3042 \funcd{fgetpos} e \funcd{fsetpos}, che invece usano il nuovo tipo
3043 \type{fpos\_t}, ed i cui prototipi sono:
3047 \funcdecl{int fsetpos(FILE *stream, fpos\_t *pos)} Imposta la posizione
3048 corrente nello \textit{stream} \param{stream} al valore specificato
3051 \funcdecl{int fgetpos(FILE *stream, fpos\_t *pos)} Legge la posizione
3052 corrente nello \textit{stream} \param{stream} e la scrive in \param{pos}.
3054 \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
3058 In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni
3059 \func{fseeko} e \func{ftello}, che sono assolutamente identiche alle
3060 precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
3061 \type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
3062 gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
3063 posizione sul file viene espressa con un valore a 64 bit come accade nei
3064 sistemi più moderni.
3066 % TODO: mettere prototipi espliciti fseeko e ftello o menzione?
3069 \section{Funzioni avanzate}
3070 \label{sec:file_stream_adv_func}
3072 In questa sezione esamineremo alcune funzioni avanzate che permettono di
3073 eseguire operazioni particolari sugli \textit{stream}, come leggerne gli
3074 attributi, controllarne le modalità di bufferizzazione, gestire direttamente i
3075 lock impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
3078 \subsection{Le funzioni di controllo}
3079 \label{sec:file_stream_cntrl}
3081 Al contrario di quanto avviene con i file descriptor, le librerie standard del
3082 C non prevedono nessuna funzione come la \func{fcntl} per il controllo degli
3083 attributi dei file. Però, dato che ogni \textit{stream} si appoggia ad un file
3084 descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
3085 il prototipo della funzione è:
3086 \begin{prototype}{stdio.h}{int fileno(FILE *stream)}
3087 Legge il file descriptor sottostante lo \textit{stream} \param{stream}.
3089 \bodydesc{Restituisce il numero del file descriptor in caso di successo, e
3090 -1 qualora \param{stream} non sia valido, nel qual caso imposta
3091 \var{errno} a \errval{EBADF}.}
3093 \noindent ed in questo modo diventa possibile usare direttamente \func{fcntl}.
3095 Questo permette di accedere agli attributi del file descriptor sottostante lo
3096 \textit{stream}, ma non ci dà nessuna informazione riguardo alle proprietà
3097 dello \textit{stream} medesimo. Le \acr{glibc} però supportano alcune
3098 estensioni derivate da Solaris, che permettono di ottenere informazioni utili.
3100 Ad esempio in certi casi può essere necessario sapere se un certo
3101 \textit{stream} è accessibile in lettura o scrittura. In genere questa
3102 informazione non è disponibile, e si deve ricordare come il file è stato
3103 aperto. La cosa può essere complessa se le operazioni vengono effettuate in
3104 una subroutine, che a questo punto necessiterà di informazioni aggiuntive
3105 rispetto al semplice puntatore allo \textit{stream}; questo può essere evitato
3106 con le due funzioni \funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui
3109 \headdecl{stdio\_ext.h}
3110 \funcdecl{int \_\_freadable(FILE *stream)}
3111 Restituisce un valore diverso da zero se \param{stream} consente la lettura.
3113 \funcdecl{int \_\_fwritable(FILE *stream)}
3114 Restituisce un valore diverso da zero se \param{stream} consente la
3117 \noindent che permettono di ottenere questa informazione.
3119 La conoscenza dell'ultima operazione effettuata su uno \textit{stream} aperto
3120 è utile in quanto permette di trarre conclusioni sullo stato del buffer e del
3121 suo contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
3122 servono a tale scopo, il loro prototipo è:
3124 \headdecl{stdio\_ext.h}
3125 \funcdecl{int \_\_freading(FILE *stream)}
3126 Restituisce un valore diverso da zero se \param{stream} è aperto in sola
3127 lettura o se l'ultima operazione è stata di lettura.
3129 \funcdecl{int \_\_fwriting(FILE *stream)}
3130 Restituisce un valore diverso da zero se \param{stream} è aperto in sola
3131 scrittura o se l'ultima operazione è stata di scrittura.
3134 Le due funzioni permettono di determinare di che tipo è stata l'ultima
3135 operazione eseguita su uno \textit{stream} aperto in lettura/scrittura;
3136 ovviamente se uno \textit{stream} è aperto in sola lettura (o sola scrittura)
3137 la modalità dell'ultima operazione è sempre determinata; l'unica ambiguità è
3138 quando non sono state ancora eseguite operazioni, in questo caso le funzioni
3139 rispondono come se una operazione ci fosse comunque stata.
3142 \subsection{Il controllo della bufferizzazione}
3143 \label{sec:file_buffering_ctrl}
3145 Come accennato in sez.~\ref{sec:file_buffering} le librerie definiscono una
3146 serie di funzioni che permettono di controllare il comportamento degli
3147 \textit{stream}; se non si è specificato nulla, la modalità di buffering viene
3148 decisa autonomamente sulla base del tipo di file sottostante, ed i buffer
3149 vengono allocati automaticamente.
3151 Però una volta che si sia aperto lo \textit{stream} (ma prima di aver compiuto
3152 operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
3153 funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
3155 \begin{prototype}{stdio.h}{int setvbuf(FILE *stream, char *buf, int mode,
3158 Imposta la bufferizzazione dello \textit{stream} \param{stream} nella
3159 modalità indicata da \param{mode}, usando \param{buf} come buffer di
3163 \bodydesc{Restituisce zero in caso di successo, ed un valore qualunque in
3164 caso di errore, nel qual caso \var{errno} viene impostata opportunamente.}
3167 La funzione permette di controllare tutti gli aspetti della bufferizzazione;
3168 l'utente può specificare un buffer da usare al posto di quello allocato dal
3169 sistema passandone alla funzione l'indirizzo in \param{buf} e la dimensione in
3172 Ovviamente se si usa un buffer specificato dall'utente questo deve essere
3173 stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
3174 \textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
3175 dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
3176 funzione, può anche essere usata una \index{variabili!automatiche} variabile
3177 automatica. In \headfile{stdio.h} è definita la macro \const{BUFSIZ}, che
3178 indica le dimensioni generiche del buffer di uno \textit{stream}; queste
3179 vengono usate dalla funzione \func{setbuf}. Non è detto però che tale
3180 dimensione corrisponda sempre al valore ottimale (che può variare a seconda
3183 Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
3184 (come delle scritture accidentali sul buffer) e non assicura la scelta delle
3185 dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
3186 di libreria, che sono in grado di farlo in maniera ottimale e trasparente
3187 all'utente (in quanto la deallocazione avviene automaticamente). Inoltre
3188 siccome alcune implementazioni usano parte del buffer per mantenere delle
3189 informazioni di controllo, non è detto che le dimensioni dello stesso
3190 coincidano con quelle su cui viene effettuato l'I/O.
3195 \begin{tabular}[c]{|l|l|}
3197 \textbf{Valore} & \textbf{Modalità} \\
3200 \const{\_IONBF} & \textit{unbuffered}\\
3201 \const{\_IOLBF} & \textit{line buffered}\\
3202 \const{\_IOFBF} & \textit{fully buffered}\\
3205 \caption{Valori dell'argomento \param{mode} di \func{setvbuf}
3206 per l'impostazione delle modalità di bufferizzazione.}
3207 \label{tab:file_stream_buf_mode}
3210 Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
3211 \val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
3212 usando il buffer allocato automaticamente dal sistema. Si potrà comunque
3213 modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
3214 opportuni valori elencati in tab.~\ref{tab:file_stream_buf_mode}. Qualora si
3215 specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
3216 vengono sempre ignorati.
3218 Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
3219 gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
3220 \funcd{setbuffer} e \funcd{setlinebuf}; i loro prototipi sono:
3224 \funcdecl{void setbuf(FILE *stream, char *buf)} Disabilita la
3225 bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
3226 come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
3228 \funcdecl{void setbuffer(FILE *stream, char *buf, size\_t size)} Disabilita
3229 la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
3230 come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
3232 \funcdecl{void setlinebuf(FILE *stream)} Pone lo \textit{stream} in modalità
3233 \textit{line buffered}.
3235 \noindent tutte queste funzioni sono realizzate con opportune chiamate a
3236 \func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
3237 BSD. Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
3238 queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
3239 \funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
3240 di uno \textit{stream}; i cui prototipi sono:
3242 \headdecl{stdio\_ext.h}
3244 \funcdecl{int \_\_flbf(FILE *stream)} Restituisce un valore diverso da zero
3245 se \param{stream} è in modalità \textit{line buffered}.
3247 \funcdecl{size\_t \_\_fbufsize(FILE *stream)} Restituisce le dimensioni del
3248 buffer di \param{stream}.
3251 Come già accennato, indipendentemente dalla modalità di bufferizzazione
3252 scelta, si può forzare lo scarico dei dati sul file con la funzione
3253 \funcd{fflush}, il suo prototipo è:
3254 \begin{prototype}{stdio.h}{int fflush(FILE *stream)}
3256 Forza la scrittura di tutti i dati bufferizzati dello
3257 \textit{stream} \param{stream}.
3259 \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
3260 errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
3261 aperto o non è aperto in scrittura, o ad uno degli errori di
3264 \noindent anche di questa funzione esiste una analoga
3265 \func{fflush\_unlocked}\footnote{accessibile definendo \macro{\_BSD\_SOURCE} o
3266 \macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
3269 % TODO aggiungere prototipo \func{fflush\_unlocked}?
3271 Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
3272 \textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
3273 essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
3274 poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
3275 line buffered; per questo motivo le \acr{glibc} supportano una estensione di
3276 Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
3277 \begin{prototype}{stdio-ext.h}{void \_flushlbf(void)}
3278 Forza la scrittura di tutti i dati bufferizzati degli \textit{stream} in
3279 modalità line buffered.
3282 Si ricordi comunque che lo scarico dei dati dai buffer effettuato da queste
3283 funzioni non comporta la scrittura di questi su disco; se si vuole che il
3284 kernel dia effettivamente avvio alle operazioni di scrittura su disco occorre
3285 usare \func{sync} o \func{fsync} (si veda~sez.~\ref{sec:file_sync}).
3287 Infine esistono anche circostanze in cui si vuole scartare tutto l'output
3288 pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
3289 \begin{prototype}{stdio.h}{int fpurge(FILE *stream)}
3291 Cancella i buffer di input e di output dello \textit{stream} \param{stream}.
3293 \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
3297 La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
3298 scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
3299 compresi gli eventuali caratteri rimandati indietro con \func{ungetc}.
3302 \subsection{Gli \textit{stream} e i \textit{thread}}
3303 \label{sec:file_stream_thread}
3307 Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
3308 allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
3309 essere consapevoli delle possibili complicazioni anche quando non si usano i
3310 \textit{thread}, dato che l'implementazione delle librerie è influenzata
3311 pesantemente dalle richieste necessarie per garantirne l'uso con i
3314 Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto
3315 ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
3316 funzioni di libreria durante la lettura e la scrittura di uno \textit{stream}
3317 devono essere opportunamente protette (in quanto il sistema assicura
3318 l'atomicità solo per le system call). Questo viene fatto associando ad ogni
3319 \textit{stream} un opportuno blocco che deve essere implicitamente acquisito
3320 prima dell'esecuzione di qualunque operazione.
3322 Ci sono comunque situazioni in cui questo non basta, come quando un
3323 \textit{thread} necessita di compiere più di una operazione sullo
3324 \textit{stream} atomicamente, per questo motivo le librerie provvedono anche
3325 delle funzioni \funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile},
3326 che permettono la gestione esplicita dei blocchi sugli \textit{stream}; esse
3327 sono disponibili definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro
3332 \funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
3333 \textit{stream} \param{stream}, bloccandosi se il lock non è disponibile.
3335 \funcdecl{int ftrylockfile(FILE *stream)} Tenta l'acquisizione del lock
3336 dello \textit{stream} \param{stream}, senza bloccarsi se il lock non è
3337 disponibile. Ritorna zero in caso di acquisizione del lock, diverso da zero
3340 \funcdecl{void funlockfile(FILE *stream)} Rilascia il lock dello
3341 \textit{stream} \param{stream}.
3343 \noindent con queste funzioni diventa possibile acquisire un blocco ed
3344 eseguire tutte le operazioni volute, per poi rilasciarlo.
3346 Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
3347 blocco non sono del tutto indolori, e quando il locking dello \textit{stream}
3348 non è necessario (come in tutti i programmi che non usano i \textit{thread}),
3349 tutta la procedura può comportare dei costi pesanti in termini di
3350 prestazioni. Per questo motivo abbiamo visto come alle usuali funzioni di I/O
3351 non formattato siano associate delle versioni \code{\_unlocked} (alcune
3352 previste dallo stesso standard POSIX, altre aggiunte come estensioni dalle
3353 \acr{glibc}) che possono essere usate quando il locking non serve\footnote{in
3354 certi casi dette funzioni possono essere usate, visto che sono molto più
3355 efficienti, anche in caso di necessità di locking, una volta che questo sia
3356 stato acquisito manualmente.} con prestazioni molto più elevate, dato che
3357 spesso queste versioni (come accade per \func{getc} e \func{putc}) sono
3358 realizzate come macro.
3360 La sostituzione di tutte le funzioni di I/O con le relative versioni
3361 \code{\_unlocked} in un programma che non usa i \textit{thread} è però un
3362 lavoro abbastanza noioso; per questo motivo le \acr{glibc} forniscono al
3363 programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni
3364 introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
3365 locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
3367 \begin{prototype}{stdio\_ext.h}{int \_\_fsetlocking (FILE *stream, int type)}
3368 Specifica o richiede a seconda del valore di \param{type} la modalità in cui
3369 le operazioni di I/O su \param{stream} vengono effettuate rispetto
3370 all'acquisizione implicita del blocco sullo \textit{stream}.
3372 \bodydesc{Restituisce lo stato di locking interno dello \textit{stream} con
3373 uno dei valori \const{FSETLOCKING\_INTERNAL} o
3374 \const{FSETLOCKING\_BYCALLER}.}
3377 La funzione imposta o legge lo stato della modalità di operazione di uno
3378 \textit{stream} nei confronti del locking a seconda del valore specificato
3379 con \param{type}, che può essere uno dei seguenti:
3380 \begin{basedescript}{\desclabelwidth{4.0cm}}
3381 \item[\const{FSETLOCKING\_INTERNAL}] Lo \textit{stream} userà da ora in poi il
3382 blocco implicito predefinito.
3383 \item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
3384 dover gestire da solo il locking dello \textit{stream}.
3385 \item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
3386 di blocco dello \textit{stream}.
3389 % TODO trattare \func{clearerr\_unlocked}
3396 %%% Local Variables:
3398 %%% TeX-master: "gapil"
3401 % LocalWords: stream cap system call kernel Ritchie glibc descriptor Stevens
3402 % LocalWords: buf read write filesystem st blksize stat sez l'header stdio BSD
3403 % LocalWords: nell'header stdin shell stdout stderr error freopen flush line
3404 % LocalWords: unbuffered buffered newline fully SVr fopen fdopen POSIX const
3405 % LocalWords: char path int fildes NULL errno malloc fcntl fclose fflush tab
3406 % LocalWords: dup fifo socket append EXCL ccs STRING IRUSR IWUSR IRGRP IWGRP
3407 % LocalWords: IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
3408 % LocalWords: sync fcloseall SOURCE void stdlib of feof ferror clearerr l'I ws
3409 % LocalWords: unlocked fread fwrite size ptr nmemb nelem gcc padding point str
3410 % LocalWords: lock thread fgetc getc getchar dell'overhead altresì unsigned ap
3411 % LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar dell'I
3412 % LocalWords: SVID getw putw parsing peeking ahead ungetc gets fgets string Di
3413 % LocalWords: overflow Aleph stack fputs puts fgetws fputws getline ssize leak
3414 % LocalWords: realloc value result argument memory getdelim delim printf short
3415 % LocalWords: fprintf sprintf format snprintf variadic long double intmax list
3416 % LocalWords: uintmax ptrdiff vprintf vfprintf vsprintf vsnprintf asprintf lex
3417 % LocalWords: vasprintf strptr dprintf vdprintf print scanf fscanf sscanf flex
3418 % LocalWords: vscanf vfscanf vsscanf bison parser yacc like off VMS whence pos
3419 % LocalWords: lseek ftell fgetpos fpos fseeko ftello fileno Solaris freadable
3420 % LocalWords: fwritable ext freading fwriting buffering setvbuf BUFSIZ setbuf
3421 % LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
3422 % LocalWords: fsync fpurge flockfile ftrylockfile funlockfile SAFE FUNCTIONS
3423 % LocalWords: locking fsetlocking type BYCALLER QUERY ll
3427 % LocalWords: descriptor system call cap like kernel sez l'inode inode VFS tab
3428 % LocalWords: process table struct files flags pos all'inode dentry fig shell
3429 % LocalWords: error POSIX STDIN FILENO STDOUT STDERR unistd read write lseek
3430 % LocalWords: close pathname sys fcntl int const char errno EEXIST CREAT EXCL
3431 % LocalWords: EISDIR ENOTDIR ENXIO NOBLOCK WRONLY fifo ENODEV ETXTBSY ELOOP of
3432 % LocalWords: NOFOLLOW EACCES ENAMETOOLONG ENOENT EROFS EFAULT ENOSPC ENOMEM
3433 % LocalWords: EMFILE ENFILE NFS lock race condition Denial Service DoS RDONLY
3434 % LocalWords: glibc RDWR NONBLOCK NOCTTY SHLOCK shared BSD EXLOCK TRUNC device
3435 % LocalWords: opendir LARGEFILE APPEND append NDELAY ASYNC l'I SIGIO SYNC SVr
3436 % LocalWords: DSYNC RSYNC filesystem DIRECT caching SGI IRIX dell'I FreeBSD fd
3437 % LocalWords: fork exec umask SOURCE creat filedes EBADF EINTR EIO locking off
3438 % LocalWords: behind sync flush shutdown whence ESPIPE socket EINVAL INCR XTND
3439 % LocalWords: SEEK CUR EPIPE ssize void buf size count EAGAIN EWOULDBLOCK log
3440 % LocalWords: Specification pwrite pread EFBIG SIGPIPE nell'inode dall'inode
3441 % LocalWords: CLOEXEC stat fsync cache update l'update bdflush Documentation
3442 % LocalWords: fdatasync fstat ext dup oldfd newfd DUPFD cmd long arg flock pid
3443 % LocalWords: SETFD GETFD GETFL SETFL GETLK SETLK SETLKW GETOWN group SIGURG
3444 % LocalWords: SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
3445 % LocalWords: truncate GETLEASE NOTIFY AND ACCMODE ioctl everything argp all'I
3446 % LocalWords: framebuffer request ENOTTY CDROM nell'header magic number openat
3447 % LocalWords: FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME redirezione FIOSETOWN
3448 % LocalWords: FIOGETOWN FIONREAD mkdirat thread Solaris mkdir at Urlich proc
3449 % LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
3450 % LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod uid
3451 % LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink gid
3452 % LocalWords: mkfifoat mkfifo FDCWD dereferenziazione rmdir REMOVEDIR
3453 % LocalWords: epoll lsattr chattr FIOQSIZE ATFILE lutimes utimensat lchown
3454 % LocalWords: lstat owner FOLLOW
3456 %%% Local Variables:
3458 %%% TeX-master: "gapil"