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 dell'I/O su 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 disposizione
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 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 dal puntatore a una struttura di tipo \kstruct{task\_struct} nella quale sono
79 raccolte tutte le informazioni relative al processo, fra queste informazioni
80 c'è anche 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.} che contiene le informazioni relative ai file che il processo
87 La \itindex{file~table} \textit{file table} è una tabella che contiene una
88 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 necessarie per la
93 gestione dei file, ed in particolare:
95 \item i flag di stato \itindex{file~status~flag} del file nel campo
97 \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
99 \item un puntatore alla struttura \kstruct{inode} che identifica
100 \itindex{inode} l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in
101 realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta
102 a sua volta \itindex{inode} all'\textit{inode} passando per la nuova
104 \item un puntatore \var{f\_op} alla tabella delle funzioni che si possono
105 usare sul file.\footnote{quelle della struttura \kstruct{file\_operation},
106 descritte sommariamente in tab.~\ref{tab:file_file_operations}.}
111 \includegraphics[width=12cm]{img/procfile}
112 \caption{Schema della architettura dell'accesso ai file attraverso
113 l'interfaccia dei \textit{file descriptor}.}
114 \label{fig:file_proc_file}
117 In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui
118 è illustrata questa architettura, ed in cui si sono evidenziate le
119 interrelazioni fra la \itindex{file~table} \textit{file table}, la
120 \itindex{process~table} \textit{process table} e le varie strutture di dati
121 che il kernel mantiene per ciascun file e ciascun processo.
123 Come si può notare alla fine il collegamento che consente di porre in
124 relazione i file ed i processi è effettuato attraverso i dati mantenuti nella
125 struttura \kstruct{files\_struct}, essa infatti contiene alcune informazioni
128 \item i flag relativi ai file aperti dal processo.
129 \item il numero di file aperti dal processo.
130 \item una tabella di puntatori alla relativa voce nella \itindex{file~table}
131 \textit{file table} per ciascun file aperto.
134 In questa infrastruttura un \textit{file descriptor} non è altro che l'intero
135 positivo che indicizza quest'ultima tabella, e che consente di recuperare il
136 puntatore alla struttura \kstruct{file} corrispondente al file aperto dal
137 processo a cui era stato assegnato questo indice. Una volta ottenuta grazie
138 al \textit{file descriptor} la struttura \kstruct{file} corrispondente al file
139 voluto nella \itindex{file~table} \textit{file table}, il kernel potrà usare
140 le funzioni messe disposizione dal VFS per eseguire sul file tutte le
141 operazioni necessarie.
143 Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo
144 \textit{file descriptor} libero nella tabella, e per questo motivo essi
145 vengono assegnati in successione tutte le volte che si apre un nuovo file,
146 posto che non ne sia stato chiuso nessuno in precedenza.
148 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
149 processo si aspetta di avere sempre tre file aperti che, per quanto appena
150 detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i
151 valori 0, 1 e 2. Il primo file è sempre associato al cosiddetto
152 \itindex{standard~input} \textit{standard input}, è cioè il file da cui un
153 processo si aspetta di dover leggere i dati in ingresso. Il secondo file è il
154 cosiddetto \itindex{standard~output} \textit{standard output}, cioè quello su
155 cui ci si aspetta di dover scrivere i dati in uscita. Il terzo è lo
156 \itindex{standard~error} \textit{standard error}, su cui vengono scritti i
157 dati relativi agli errori.
159 Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
160 delle applicazioni, e non aderirvi potrebbe portare a problemi di
161 interoperabilità. Nel caso della shell tutti questi file sono associati al
162 terminale di controllo, e corrispondono quindi alla lettura della tastiera per
163 l'ingresso e alla scrittura sul terminale per l'uscita. Lo standard POSIX.1
164 provvede, al posto dei valori numerici, tre costanti simboliche, definite in
165 tab.~\ref{tab:file_std_files}.
170 \begin{tabular}[c]{|l|l|}
172 \textbf{File} & \textbf{Significato} \\
175 \const{STDIN\_FILENO} & \textit{file descriptor} dello \textit{standard
177 \const{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
179 \const{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
183 \caption{Costanti definite in \headfile{unistd.h} per i file standard.}
184 \label{tab:file_std_files}
187 In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa
188 rispetto a quella usuale della shell, in cui tutti e tre questi file fanno
189 riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata
190 la situazione di un programma in cui lo \itindex{standard~input}
191 \textit{standard input} è associato ad un file mentre lo
192 \itindex{standard~output} \textit{standard output} e lo
193 \itindex{standard~error} \textit{standard error} sono associati ad un altro
194 file. Si noti poi come per questi ultimi le strutture \kstruct{file} nella
195 \itindex{file~table} \textit{file table}, pur essendo distinte, fanno
196 riferimento allo stesso \itindex{inode} \textit{inode}, dato che il file che è
197 stato aperto lo stesso. Questo è quello che avviene normalmente quando si apre
198 più volte lo stesso file.
200 Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file
201 table} una situazione analoga di quella delle voci di una directory, con la
202 possibilità di avere più voci che fanno riferimento allo stesso
203 \itindex{inode} \textit{inode}. L'analogia è in realtà molto stretta perché
204 quando si cancella un file, il kernel verifica anche che non resti nessun
205 riferimento in una una qualunque voce della \itindex{file~table} \textit{file
206 table} prima di liberare le risorse ad esso associate e disallocare il
207 relativo \itindex{inode} \textit{inode}.
209 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
210 numero di file aperti era anche soggetto ad un limite massimo dato dalle
211 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
212 descriptor dentro \kstruct{files\_struct}. Questo limite intrinseco nei kernel
213 più recenti non sussiste più, dato che si è passati da un vettore ad una
214 lista, ma restano i limiti imposti dall'amministratore (vedi
215 sez.~\ref{sec:sys_limits}).
219 \subsection{Apertura e creazione di un file}
220 \label{sec:file_open}
222 La funzione di sistema \funcd{open} è la principale funzione dell'interfaccia
223 di gestione dei file, quella che dato un \textit{pathname} consente di
224 ottenere un file descriptor ``\textsl{aprendo}'' il file
225 corrispondente,\footnote{è \func{open} che alloca \kstruct{file}, la inserisce
226 nella \itindex{file~table} \textit{file table} e crea il riferimento nella
227 \kstruct{files\_struct} del processo.} il suo prototipo è:
233 \fdecl{int open(const char *pathname, int flags)}
234 \fdecl{int open(const char *pathname, int flags, mode\_t mode)}
236 \fdesc{Apre un file.}
239 {La funzione ritorna il file descriptor in caso di successo e $-1$ per un
240 errore, nel qual caso \var{errno} assumerà uno dei valori:
242 \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
243 \const{O\_CREAT} e \const{O\_EXCL}.
244 \item[\errcode{EINTR}] la funzione era bloccata ed è stata interrotta da un
245 segnale (vedi sez.~\ref{sec:sig_gen_beha}).
246 \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
247 l'accesso in scrittura o in lettura/scrittura.
248 \item[\errcode{EFBIG}] il file è troppo grande per essere aperto (lo
249 standard richiederebbe \errval{EOVERFLOW}).
250 \item[\errcode{ELOOP}] si sono incontrati troppi collegamenti simbolici nel
251 risolvere \param{pathname} o si è indicato \const{O\_NOFOLLOW} e
252 \param{pathname} è un collegamento simbolico.
253 \item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
254 dispositivo che non esiste.
255 \item[\errcode{ENOENT}] \param{pathname} non esiste e non si è richiesto
256 \const{O\_CREAT}, o non esiste un suo componente.
257 \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
258 \param{pathname} non è una directory.
259 \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
260 \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
261 processo o \param{pathname} è un file di dispositivo ma il dispositivo è
263 \item[\errcode{EPERM}] si è specificato \const{O\_NOATIME} e non si è né
264 amministratori né proprietari del file.
265 \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
266 di un programma in esecuzione.
267 \item[\errcode{EWOULDBLOCK}] la funzione si sarebbe bloccata ma si è
268 richiesto \const{O\_NOBLOCK}.
270 ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EMFILE},
271 \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM}, \errval{ENOSPC},
272 \errval{EROFS}, nel loro significato generico.}
275 La funzione apre il file indicato da \param{pathname} nella modalità indicata
276 da \param{flags}. Essa può essere invocata in due modi diversi, specificando
277 opzionalmente un terzo argomento \param{mode}. Qualora il file non esista e
278 venga creato, questo argomento consente di indicare quali permessi dovranno
279 essergli assegnati. I valori possibili sono gli stessi già visti in
280 sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
281 delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
282 comunque filtrati dal valore della \itindex{umask} \textit{umask} (vedi
283 sez.~\ref{sec:file_perm_management}) del processo.
285 La funzione restituisce sempre il primo file descriptor libero, una
286 caratteristica che permette di prevedere qual è il valore del file descriptor
287 che si otterrà al ritorno di \func{open}, e che viene spesso usata dalle
288 applicazioni per sostituire i file corrispondenti ai file standard visti in
289 tab.~\ref{tab:file_std_files}. Se ad esempio si chiude lo
290 \itindex{standard~input} \textit{standard input} e si apre subito dopo un
291 nuovo file questo diventerà il nuovo \itindex{standard~input} \textit{standard
292 input} dato che avrà il file descriptor 0.
294 Al momento dell'apertura il nuovo file descriptor non è condiviso con nessun
295 altro processo (torneremo sul significato della condivisione dei file
296 descriptor, che in genere si ottiene dopo una \func{fork}, in
297 sez.~\ref{sec:file_sharing}) ed è impostato, come accennato in
298 sez.~\ref{sec:proc_exec}, per restare aperto attraverso una
299 \func{exec}. Inoltre la posizione sul file, il cosiddetto \textit{offset}, è
300 impostata all'inizio del file. Una volta aperto un file si potrà operare su di
301 esso direttamente tramite il file descriptor, e quanto avviene al
302 \textit{pathname} con cui lo si è aperto sarà del tutto ininfluente.
304 Il comportamento della funzione, e le diverse modalità con cui può essere
305 aperto il file, vengono controllati dall'argomento \param{flags} il cui valore
306 deve essere indicato come maschera binaria in cui ciascun bit ha un
307 significato specifico. Alcuni di questi bit vanno anche a costituire i
308 cosiddetti \textsl{flag di stato} del file (i cosiddetti
309 \itindex{file~status~flag} \textit{file status flags}), che vengono mantenuti
310 nel campo \var{f\_flags} della struttura \kstruct{file} che abbiamo riportato
311 anche in fig.~\ref{fig:file_proc_file}).
313 Ciascun flag viene identificato da una apposita costante, ed il valore
314 di \param{flags} deve essere specificato come OR aritmetico di queste
315 costanti. I vari bit che si possono usare come componenti di \param{flags}
316 sono divisi in tre gruppi principali. Il primo gruppo è quello dei cosiddetti
317 flag delle \textsl{modalità di accesso} (o \textit{access mode flags}), che
318 specificano che tipo di accesso si effettuerà sul file, fra lettura, scrittura
319 e lettura/scrittura. Questa modalità deve essere indicata usando una delle
320 costanti di tab.~\ref{tab:open_access_mode_flag}.
325 \begin{tabular}[c]{|l|l|}
327 \textbf{Flag} & \textbf{Significato} \\
330 \const{O\_RDONLY} & Apre il file in sola lettura.\\
331 \const{O\_WRONLY} & Apre il file in sola scrittura.\\
332 \const{O\_RDWR} & Apre il file sia in lettura che in scrittura.\\
335 \caption{Le tre costanti che identificano le modalità di accesso
336 nell'apertura di un file.}
337 \label{tab:open_access_mode_flag}
340 A differenza di tutti gli altri flag che vedremo in seguito, in questo caso
341 non si ha a che fare con singoli bit separati dell'argomento \param{flags}, ma
342 con un numero composto da due bit. Questo significa ad esempio che la
343 combinazione \code{\const{O\_RDONLY}|\const{O\_WRONLY}} non è affatto
344 equivalente a \const{O\_RDWR}, e non deve essere usata.\footnote{in realtà
345 su Linux, dove i valori per le tre costanti di
346 tab.~\ref{tab:open_access_mode_flag} sono rispettivamente $0$, $1$ e $2$, il
347 valore $3$ viene usato con un significato speciale, ed assolutamente fuori
348 standard, disponibile solo per i file di dispositivo e solo per alcuni
349 driver, in cui si richiede la verifica della capacità di accesso in lettura
350 e scrittura ma viene restituito un file descriptor che non può essere letto
351 o scritto, ma solo usato con una \func{ioctl} (vedi
352 sez.~\ref{sec:file_ioctl}).}
354 La modalità di accesso deve sempre essere specificata quando si apre un file,
355 il valore indicato in \param{flags} viene salvato nei
356 \itindex{file~status~flag} \textit{file status flags}, e può essere riletto
357 con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}), il relativo valore può
358 essere poi ottenuto un AND aritmetico della maschera binaria
359 \const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
360 definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
361 \const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
362 definizioni completamente fuori standard, attinenti, insieme a
363 \const{O\_EXEC} che permetterebbe l'apertura di un file per l'esecuzione, ad
364 un non meglio precisato ``\textit{GNU system}''; pur essendo equivalenti
365 alle definizioni classiche non è comunque il caso di utilizzarle.}
367 Il secondo gruppo di flag è quello delle \textsl{modalità di
368 apertura},\footnote{la pagina di manuale di \func{open} parla di
369 \textit{file creation flags}, ma alcuni di questi flag non hanno nulla a che
370 fare con la creazione dei file, mentre il manuale dalla \acr{glibc} parla di
371 più correttamente di \textit{open-time flags}, dato che si tratta di flag il
372 cui significato ha senso solo al momento dell'apertura del file.} che
373 permettono di specificare alcune delle caratteristiche del comportamento di
374 \func{open} nel momento in viene eseguita per aprire un file. Questi flag
375 hanno effetto solo nella chiamata della funzione, non sono memorizzati fra i
376 \itindex{file~status~flag} \textit{file status flags} e non possono essere
377 riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
382 \begin{tabular}[c]{|l|p{10 cm}|}
384 \textbf{Flag} & \textbf{Significato} \\
387 \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole
388 di titolarità del file viste in
389 sez.~\ref{sec:file_ownership_management}. Se si
390 imposta questo flag l'argomento \param{mode} deve
391 essere sempre specificato.\\
392 \const{O\_DIRECTORY}& Se \param{pathname} non è una directory la
393 chiamata fallisce. Questo flag, introdotto con il
394 kernel 2.1.126, è specifico di Linux e
395 serve ad evitare dei possibili
396 \itindex{Denial~of~Service~(DoS)}
397 \textit{DoS}\footnotemark quando \func{opendir}
398 viene chiamata su una fifo o su un dispositivo
399 associato ad una unità a nastri. Non viene
400 usato al di fuori dell'implementazione di
401 \func{opendir}, ed è utilizzabile soltanto se si è
402 definita la macro \macro{\_GNU\_SOURCE}.\\
403 \const{O\_EXCL} & Deve essere usato in congiunzione con
404 \const{O\_CREAT} ed in tal caso impone che il file
405 indicato da \param{pathname} non sia già esistente
406 (altrimenti causa il fallimento della chiamata con
407 un errore di \errcode{EEXIST}).\\
408 \const{O\_LARGEFILE}& Viene usato sui sistemi a 32 bit per richiedere
409 l'apertura di file molto grandi, la cui
410 dimensione non è rappresentabile con la versione a
411 32 bit del tipo \type{off\_t}, utilizzando
412 l'interfaccia alternativa abilitata con la
413 macro \macro{\_LARGEFILE64\_SOURCE}. Come
414 illustrato in sez.~\ref{sec:intro_gcc_glibc_std} è
415 sempre preferibile usare la conversione automatica
416 delle funzioni che si attiva assegnando a $64$ la
417 macro \macro{\_FILE\_OFFSET\_BITS}, e non usare mai
419 \const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo
420 di terminale, questo non diventerà il terminale di
421 controllo, anche se il processo non ne ha ancora
422 uno (si veda sez.~\ref{sec:sess_ctrl_term}).\\
423 \const{O\_NOFOLLOW} & Se \param{pathname} è un collegamento simbolico
424 la chiamata fallisce. Questa è un'estensione BSD
425 aggiunta in Linux a partire dal kernel
426 2.1.126, ed utilizzabile soltanto se si è definita
427 la macro \macro{\_GNU\_SOURCE}.\\
428 \const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
429 ne tronca la lunghezza a zero; con un terminale o
430 una fifo viene ignorato, negli altri casi il
431 comportamento non è specificato.\\
434 \caption{Le costanti che identificano le \textit{modalità di apertura} di
436 \label{tab:open_time_flag}
439 \footnotetext{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{Denial of
440 Service}, si chiamano così attacchi miranti ad impedire un servizio
441 causando una qualche forma di carico eccessivo per il sistema, che resta
442 bloccato nelle risposte all'attacco.}
444 Si è riportato in tab.~\ref{tab:open_time_flag} l'elenco dei flag delle
445 \textsl{modalità di apertura}.\footnote{la \acr{glibc} definisce anche i due
446 flag \const{O\_SHLOCK}, che aprirebbe il file con uno \textit{shared lock} e
447 \const{O\_EXLOCK} che lo aprirebbe con un \textit{exclusive lock} (vedi
448 sez.~\ref{sec:file_locking}, si tratta di opzioni specifiche di BSD, che non
449 esistono con Linux.} Uno di questi, \const{O\_EXCL}, ha senso solo se usato
450 in combinazione a \const{O\_CREAT} quando si vuole creare un nuovo file per
451 assicurarsi che questo non esista di già, e lo si usa spesso per creare i
452 cosiddetti \index{file!di lock} ``\textsl{file di lock}'' (vedi
453 sez.~\ref{sec:ipc_file_lock}). Si tenga presente che questa opzione è
454 supportata su NFS solo a partire da NFSv3 e con il kernel 2.6, nelle versioni
455 precedenti la funzionalità viene emulata controllando prima l'esistenza del
456 file per cui usarla per creare \index{file!di lock} un file di lock potrebbe
457 dar luogo a una \itindex{race~condition} \textit{race condition}.\footnote{un
458 file potrebbe venir creato fra il controllo la successiva apertura con
459 \const{O\_CREAT}, la cosa si può risolvere comunque creando un file con un
460 nome univoco ed usando la funzione \func{link} per creare il \index{file!di
461 lock} file di lock, (vedi sez.~\ref{sec:ipc_file_lock}).}
463 Se si usa \const{O\_EXCL} senza \const{O\_CREAT} il comportamento è
464 indefinito. Nella creazione di un file con \const{O\_CREAT} occorre sempre
465 specificare l'argomento di \param{mode}, che altrimenti è ignorato. Si tenga
466 presente che indipendentemente dai permessi che si possono assegnare, che in
467 seguito potrebbero non consentire lettura o scrittura, quando il file viene
468 aperto l'accesso viene garantito secondo quanto richiesto con i flag di
469 tab.~\ref{tab:open_access_mode_flag}. Quando viene creato un nuovo file
470 \const{O\_CREAT} con tutti e tre i tempi del file di
471 tab.~\ref{tab:file_file_times} vengono impostati al tempo corrente. Se invece
472 si tronca il file con \const{O\_TRUNC} verranno impostati soltanto il
473 \textit{modification time} e lo \textit{status change time}.
478 \begin{tabular}[c]{|l|p{10 cm}|}
480 \textbf{Flag} & \textbf{Significato} \\
483 \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
484 \textit{append mode}. La posizione sul file (vedi
485 sez.~\ref{sec:file_lseek}) viene sempre mantenuta
486 sulla sua coda, per cui quanto si scrive
487 viene sempre aggiunto al contenuto precedente. Con
488 NFS questa funzionalità non è supportata
489 e viene emulata, per questo possono verificarsi
490 \itindex{race~condition} \textit{race
491 condition} con una sovrapposizione dei dati se
492 più di un processo scrive allo stesso tempo. \\
493 \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
494 sez.~\ref{sec:file_asyncronous_io}). Quando è
495 impostato viene generato il segnale \signal{SIGIO}
496 tutte le volte che il file è pronto per le
497 operazioni di lettura o scrittura. Questo flag si
498 può usare solo terminali, pseudo-terminali e socket
499 e, a partire dal kernel 2.6, anche sulle fifo.\\
500 \const{O\_CLOEXEC}& Attiva la modalità di \itindex{close-on-exec}
501 \textit{close-on-exec} (vedi
502 sez.~\ref{sec:proc_exec}) sul file. Il flag è
503 previsto dallo standard POSIX.1-2008, ed è stato
504 introdotto con il kernel 2.6.23 per evitare una
505 \itindex{race~condition} \textit{race condition}
506 che si potrebbe verificare con i \textit{thread}
507 fra l'apertura del file e l'impostazione della
508 suddetta modalità con \func{fcntl} (vedi
509 sez.~\ref{sec:file_fcntl}).\\
510 \const{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
511 \textit{user space} in maniera sincrona, in modo da
512 scavalcare i meccanismi di bufferizzazione del
513 kernel. Introdotto con il kernel 2.4.10 ed
514 utilizzabile soltanto se si è definita la
515 macro \macro{\_GNU\_SOURCE}.\\
516 \const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
517 file (vedi sez.~\ref{sec:file_file_times}). Per
518 molti filesystem questa funzionalità non è
519 disponibile per il singolo file ma come opzione
520 generale da specificare in fase di montaggio.\\
521 \const{O\_NONBLOCK}& Apre il file in \textsl{modalità non bloccante} per
522 le operazioni di I/O (vedi
523 sez.~\ref{sec:file_noblocking}). Questo significa
524 il fallimento delle successive operazioni di
525 lettura o scrittura qualora il file non sia pronto
526 per la loro esecuzione immediata, invece del
527 blocco delle stesse in attesa di una successiva
528 possibilità di esecuzione come avviene
529 normalmente. Questa modalità ha senso solo per le
530 fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
531 si vuole aprire un file di dispositivo per eseguire
532 una \func{ioctl} (vedi
533 sez.~\ref{sec:file_ioctl}).\\
534 \const{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
535 origina da SVr4, dove però causava il ritorno da
536 una \func{read} con un valore nullo e non con un
537 errore, questo introduce un'ambiguità, dato che
538 come vedremo in sez.~\ref{sec:file_read} il ritorno
539 di un valore nullo da parte di \func{read} ha
540 il significato di una \textit{end-of-file}.\\
541 \const{O\_SYNC} & Apre il file per l'input/output sincrono. Ogni
542 scrittura si bloccherà fino alla conferma
543 dell'arrivo di tutti i dati e di tutti i metadati
544 sull'hardware sottostante (in questo significato
545 solo dal kernel 2.6.33).\\
546 \const{O\_DSYNC} & Apre il file per l'input/output sincrono. Ogni
547 scrittura di dati si bloccherà fino alla conferma
548 dell'arrivo degli stessi e della parte di metadati
549 ad essi relativa sull'hardware sottostante (in
550 questo significato solo dal kernel 2.6.33).\\
553 \caption{Le costanti che identificano le \textit{modalità di operazione} di
555 \label{tab:open_operation_flag}
558 Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione},
559 riportati in tab.~\ref{tab:open_operation_flag}, che permettono di specificare
560 varie caratteristiche del comportamento delle operazioni di I/O che verranno
561 eseguite sul file. Tutti questi, tranne \const{O\_CLOEXEC}, che viene
562 mantenuto per ogni singolo file descriptor, vengono salvati nel campo
563 \var{f\_flags} della struttura \kstruct{file} insieme al valore della
564 \textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
565 status flags}. Il loro valore viene impostato alla chiamata di \func{open},
566 ma possono essere riletti ed in alcuni di essi anche modificati, con
567 conseguente effetto sulle caratteristiche operative che controllano, con
568 \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
570 Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
571 presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
572 SGI in IRIX, ma è presente senza limiti di allineamento dei buffer anche in
573 FreeBSD.} Per i kernel della serie 2.4 si deve garantire che i buffer in
574 \textit{user space} da cui si effettua il trasferimento diretto dei dati siano
575 allineati alle dimensioni dei blocchi del filesystem. Con il kernel 2.6 in
576 genere basta che siano allineati a multipli di 512 byte, ma le restrizioni
577 possono variare a seconda del filesystem, ed inoltre su alcuni filesystem può
578 non essere supportato, nel qual caso si avrà un errore di \errval{EINVAL}.
580 Lo scopo di \const{O\_DIRECT} è consentire un completo controllo sulla
581 bufferizzazione dei propri dati per quelle applicazioni (in genere database)
582 che hanno esigenze specifiche che non vengono soddisfatte nella maniera più
583 efficiente dalla politica generica utilizzata dal kernel. In genere l'uso di
584 questo flag peggiora le prestazioni tranne quando le applicazioni sono in
585 grado di ottimizzare la propria bufferizzazione in maniera adeguata. Se lo si
586 usa si deve avere cura di non mescolare questo tipo di accesso con quello
587 ordinario, in quante le esigenze di mantenere coerenti i dati porterebbero ad
588 un peggioramento delle prestazioni. Lo stesso dicasi per l'interazione con
589 eventuale mappatura in memoria del file (vedi sez.~\ref{sec:file_memory_map}).
591 Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta
592 sostanzialmente solo una scrittura sincrona dei dati dei buffer in
593 \textit{user space}, questo non è completamente equivalente all'uso di
594 \const{O\_SYNC} che garantisce anche sulla scrittura sincrona dei metadati
595 associati alla scrittura dei dati del file. Per questo in genere è opportuno
596 se si usa \const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
598 Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
599 differisce da quanto previsto dallo standard POSIX.1 che prevede, oltre a
600 questo flag che dovrebbe indicare la sincronizzazione completa di tutti i dati
601 e di tutti i metadati, altri due flag \const{O\_DSYNC} e \const{O\_RSYNC}. Il
602 primo dei due richiede la scrittura sincrona di tutti i dati del file e dei
603 metadati che ne consentono l'immediata rilettura, ma non di tutti i metadati,
604 per evitare la perdita di prestazioni relativa alla sincronizzazione di
605 informazioni ausiliarie come i tempi dei file.
607 Il secondo, da usare in combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne
608 sospende l'effetto, consentendo al kernel di bufferizzare le scritture, ma
609 soltanto finché non avviene una lettura, in quel caso i dati ed i metadati
610 dovranno essere sincronizzati immediatamente (secondo le modalità indicate da
611 \const{O\_SYNC} e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che
612 detta sincronizzazione non sia completata.
614 Nel caso di Linux, fino al kernel 2.6.33, esisteva solo \const{O\_SYNC}, ma
615 con il comportamento previsto dallo standard per \const{O\_DSYNC}, e sia
616 questo che \const{O\_RSYNC} erano definiti (fin dal kernel 2.1.130) come
617 sinonimi di \const{O\_SYNC}. Con il kernel 2.6.33 il significato di
618 \const{O\_SYNC} è diventato quello dello standard, ma gli è stato assegnato un
619 valore diverso, mantenendo quello originario, con il comportamento
620 corrispondete, per \const{O\_DSYNC}.
622 % NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
623 % nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
625 Nelle prime versioni di Unix i valori di \param{flag} specificabili per
626 \func{open} erano solo quelli relativi alle modalità di accesso del file. Per
627 questo motivo per creare un nuovo file c'era una \textit{system call}
628 apposita, \funcd{creat}, nel caso di Linux questo non è più necessario ma la
629 funzione è definita ugualmente; il suo prototipo è:
633 \fdecl{int creat(const char *pathname, mode\_t mode)}
634 \fdesc{Crea un nuovo file vuoto.}
637 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
638 caso \var{errno} assumerà gli stessi valori che si otterrebbero con
642 La funzione crea un nuovo file vuoto, con i permessi specificati
643 dall'argomento \param{mode}. È del tutto equivalente a \code{open(filedes,
644 O\_CREAT|O\_WRONLY|O\_TRUNC, mode)} e resta solo per compatibilità con i
648 \subsection{La funzione \func{close}}
649 \label{sec:file_close}
651 Una volta che l'accesso ad un file non sia più necessario la funzione di
652 sistema \funcd{close} permette di ``\textsl{chiuderlo}'', in questo modo il
653 file non sarà più accessibile ed il relativo file descriptor ritornerà
654 disponibile; il suo prototipo è:
658 \fdecl{int close(int fd)}
659 \fdesc{Chiude un file.}
662 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
663 caso \var{errno} assumerà uno dei valori:
665 \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
666 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
668 ed inoltre \errval{EIO} nel suo significato generico.}
671 La funzione chiude il file descriptor \param{fd}, la chiusura rilascia ogni
672 blocco (il \textit{file locking} \itindex{file~locking} è trattato in
673 sez.~\ref{sec:file_locking}) che il processo poteva avere acquisito su di
674 esso. Se \param{fd} è l'ultimo riferimento (di eventuali copie, vedi
675 sez.~\ref{sec:file_sharing} e \ref{sec:file_dup}) ad un file aperto, tutte le
676 risorse nella \itindex{file~table} \textit{file table} vengono
677 rilasciate. Infine se il file descriptor era l'ultimo riferimento ad un file
678 su disco quest'ultimo viene cancellato.
680 Si ricordi che quando un processo termina tutti i suoi file descriptor vengono
681 automaticamente chiusi, molti programmi sfruttano questa caratteristica e non
682 usano esplicitamente \func{close}. In genere comunque chiudere un file senza
683 controllare lo stato di uscita di \func{close} un è errore; molti filesystem
684 infatti implementano la tecnica del cosiddetto \textit{write-behind}, per cui
685 una \func{write} può avere successo anche se i dati non sono stati
686 effettivamente scritti su disco. In questo caso un eventuale errore di I/O
687 avvenuto in un secondo tempo potrebbe sfuggire, mentre verrebbe riportato alla
688 chiusura esplicita del file. Per questo motivo non effettuare il controllo può
689 portare ad una perdita di dati inavvertita.\footnote{in Linux questo
690 comportamento è stato osservato con NFS e le quote su disco.}
692 In ogni caso una \func{close} andata a buon fine non garantisce che i dati
693 siano stati effettivamente scritti su disco, perché il kernel può decidere di
694 ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
695 \func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
696 \emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
697 comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
698 dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
699 di ripetere tre volte il comando prima di eseguire lo shutdown).
702 \subsection{La gestione della posizione nel file}
703 \label{sec:file_lseek}
705 Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
706 una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
707 mantenuto nel campo \var{f\_pos} di \kstruct{file}) espressa da un numero
708 intero positivo che esprime il numero di byte dall'inizio del file. Tutte le
709 operazioni di lettura e scrittura avvengono a partire da questa posizione che
710 viene automaticamente spostata in avanti del numero di byte letti o scritti.
712 In genere, a meno di non avere richiesto la modalità \itindex{append~mode} di
713 \textit{append} con \const{O\_APPEND}, questa posizione viene impostata a zero
714 all'apertura del file. È possibile impostarla ad un valore qualsiasi con la
715 funzione si sistema \funcd{lseek}, il cui prototipo è:
720 \fdecl{off\_t lseek(int fd, off\_t offset, int whence)}
721 \fdesc{Imposta la posizione sul file..}
724 {La funzione ritorna il valore della posizione sul file in caso di successo e
725 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
727 \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
728 \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
729 \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
732 ed inoltre \errval{EBADF} nel suo significato generico.}
735 La funzione imposta la nuova posizione sul file usando il valore specificato
736 da \param{offset}, che viene sommato al riferimento dato
737 dall'argomento \param{whence}. Quest'ultimo deve essere indicato con una delle
738 costanti riportate in tab.~\ref{tab:lseek_whence_values}.\footnote{per
739 compatibilità con alcune vecchie notazioni questi valori possono essere
740 rimpiazzati rispettivamente con 0, 1 e 2 o con \const{L\_SET},
741 \const{L\_INCR} e \const{L\_XTND}.}
746 \begin{tabular}[c]{|l|p{8cm}|}
748 \textbf{Costante} & \textbf{Significato} \\
751 \const{SEEK\_SET} & Si fa riferimento all'inizio del file: il valore, che
752 deve essere positivo, di \param{offset} indica
753 direttamente la nuova posizione corrente.\\
754 \const{SEEK\_CUR} & Si fa riferimento alla posizione corrente del file:
755 ad essa viene sommato \param{offset}, che può essere
756 negativo e positivo, per ottenere la nuova posizione
758 \const{SEEK\_END} & Si fa riferimento alla fine del file: alle dimensioni
759 del file viene sommato \param{offset}, che può essere
760 negativo e positivo, per ottenere la nuova posizione
763 \const{SEEK\_DATA}& Sposta la posizione nel file sull'inizio del primo
764 blocco di dati dopo un \textit{hole} che segue (o
765 coincide) con la posizione indicata da \param{offset}.\\
766 \const{SEEK\_HOLE}& Sposta la posizione sul file all'inizio del primo
767 \textit{hole} nel file che segue o inizia
768 con \param{offset}, oppure \param{offset} se questo è
769 all'interno di un \textit{hole} o alla fine del file
770 se non ci sono \textit{hole} dopo \param{offset}.\\
773 \caption{Possibili valori per l'argomento \param{whence} di \func{lseek}.}
774 \label{tab:lseek_whence_values}
778 % NOTE: per SEEK_HOLE e SEEK_DATA, inclusi nel kernel 3.1, vedi
779 % http://lwn.net/Articles/439623/
781 Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
782 file, si limita a modificare la posizione corrente (cioè il campo \var{f\_pos}
783 della struttura \kstruct{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che
784 la funzione ritorna la nuova posizione, usando il valore zero
785 per \param{offset} si può riottenere la posizione corrente nel file chiamando
786 la funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
788 Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
789 la successiva scrittura avvenga alla fine del file, infatti se questo è stato
790 aperto anche da un altro processo che vi ha scritto, la fine del file può
791 essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
792 (questa è una potenziale sorgente di \itindex{race~condition} \textit{race
793 condition}, vedi sez.~\ref{sec:file_atomic}).
795 Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
796 questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
797 per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
798 non supportano questa funzione, come ad esempio per i file di
799 terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
800 ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
801 POSIX però non specifica niente in proposito. Inoltre alcuni
802 \index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
803 un errore ma restituiscono un valore indefinito.
805 \itindbeg{sparse~file}
807 Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
808 con \func{lseek} è possibile impostare una posizione anche oltre la corrente
809 fine del file. In tal caso alla successiva scrittura il file sarà esteso a
810 partire da detta posizione, ed in questo si ha quella che viene chiamata la
811 creazione di un \index{file!\textit{hole}} \textsl{buco} nel file. Il nome
812 deriva dal fatto che nonostante la dimensione del file sia cresciuta in
813 seguito alla scrittura effettuata, lo spazio vuoto fra la precedente fine del
814 file ed la nuova parte scritta dopo lo spostamento non corrisponde ad una
815 allocazione effettiva di spazio su disco, che sarebbe inutile dato che quella
816 zona è effettivamente vuota.
818 Questa è una delle caratteristiche specifiche della gestione dei file di un
819 sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
820 chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
821 file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
822 struttura di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail},
823 quello che accade è che nell'\textit{inode} del file viene segnata
824 l'allocazione di un blocco di dati a partire dalla nuova posizione, ma non
825 viene allocato nulla per le posizioni intermedie; in caso di lettura
826 sequenziale del contenuto del file il kernel si accorgerà della presenza del
827 buco, e restituirà degli zeri come contenuto di quella parte del file.
829 Questa funzionalità comporta una delle caratteristiche della gestione dei file
830 su Unix che spesso genera più confusione in chi non la conosce, per cui
831 sommando le dimensioni dei file si può ottenere, se si hanno molti
832 \textit{sparse file}, un totale anche maggiore della capacità del proprio
833 disco e comunque maggiore della dimensione che riporta un comando come
834 \cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
835 effettivamente allocati per il file.
837 Questo avviene proprio perché in un sistema unix-like la dimensione di un file
838 è una caratteristica del tutto indipendente dalla quantità di spazio disco
839 effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
840 proprietà del file. La dimensione viene aggiornata automaticamente quando si
841 estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
842 struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
843 \texttt{*stat} viste in sez.~\ref{sec:file_stat}.
845 Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
846 la dimensione di un file sarà più o meno corrispondente alla quantità di
847 spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
848 sposta in una posizione oltre la fine corrente del file, o come quello
849 accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
850 di un file con una \func{truncate}, in cui in sostanza di modifica il valore
851 della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
852 consente di creare inizialmente file di dimensioni anche molto grandi, senza
853 dover occupare da subito dello spazio disco che in realtà sarebbe
856 \itindend{sparse~file}
859 \subsection{Le funzioni per la lettura}
860 \label{sec:file_read}
862 Una volta che un file è stato aperto (con il permesso in lettura) si possono
863 leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
868 \fdecl{ssize\_t read(int fd, void * buf, size\_t count)}
869 \fdesc{Legge i dati da un file.}
872 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
873 caso \var{errno} assumerà uno dei valori:
877 nel loro significato generico.}
880 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
882 Cerca di leggere \param{count} byte dal file \param{fd} al buffer
885 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
886 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
888 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
889 aver potuto leggere qualsiasi dato.
890 \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
891 era aperto il file in modalità \const{O\_NONBLOCK}.
893 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
894 \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
895 natura dell'oggetto connesso a \param{fd}.}
898 La funzione tenta di leggere \param{count} byte a partire dalla posizione
899 corrente nel file. Dopo la lettura la posizione sul file è spostata
900 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
901 funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
902 presente che non è detto che la funzione \func{read} restituisca sempre il
903 numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
904 può restituire un numero di byte inferiore; questo è un comportamento normale,
905 e non un errore, che bisogna sempre tenere presente.
907 La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
908 di quanto il file ne contenga. In questo caso il file viene letto fino alla
909 sua fine, e la funzione ritorna regolarmente il numero di byte letti
910 effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
911 di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La
912 condizione di raggiungimento della fine del file non è un errore, e viene
913 segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
914 ulteriormente la lettura non avrebbe nessun effetto se non quello di
915 continuare a ricevere zero come valore di ritorno.
917 Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
918 un numero di byte letti inferiore a quello richiesto, ma questo non è vero
919 quando si legge da un terminale, da una fifo o da una pipe. In tal caso
920 infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
921 non aver selezionato la modalità non bloccante, vedi
922 sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
923 di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
924 con un numero di byte inferiore a quelli richiesti.
926 Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
927 come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
928 di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
929 singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
930 dati ricevuti fino al momento della lettura.
932 Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
933 \errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
934 quando la \func{read} è bloccata in attesa di dati in ingresso e viene
935 interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
936 rieseguire la funzione. Torneremo in dettaglio sull'argomento in
937 sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
938 in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
939 dati in ingresso: la funzione allora ritorna immediatamente con un errore
940 \errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
941 \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
942 \errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
943 disponibili occorre provare a ripetere la lettura in un secondo tempo.
945 La funzione \func{read} è una delle \textit{system call} fondamentali,
946 esistenti fin dagli albori di Unix, ma nella seconda versione delle
947 \textit{Single Unix Specification}\footnote{questa funzione, e l'analoga
948 \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nelle
949 \acr{glibc}, compresa l'emulazione per i vecchi kernel che non hanno la
950 \textit{system call}, è stato aggiunto con la versione 2.1, in versioni
951 precedenti sia del kernel che delle librerie la funzione non è disponibile.}
952 (quello che viene chiamato normalmente Unix98, vedi
953 sez.~\ref{sec:intro_xopen}) è stata introdotta la definizione di un'altra
954 funzione di lettura, \funcd{pread}, il cui prototipo è:
955 \begin{prototype}{unistd.h}
956 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
958 Cerca di leggere \param{count} byte dal file \param{fd}, a partire dalla
959 posizione \param{offset}, nel buffer \param{buf}.
961 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
962 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
963 visti per \func{read} e \func{lseek}.}
966 La funzione prende esattamente gli stessi argomenti di \func{read} con lo
967 stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
968 una posizione sul file. Identico è il comportamento ed il valore di
969 ritorno. La funzione serve quando si vogliono leggere dati dal file senza
970 modificare la posizione corrente.
972 L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
973 da una \func{lseek} che riporti al valore precedente la posizione corrente sul
974 file, ma permette di eseguire l'operazione atomicamente. Questo può essere
975 importante quando la posizione sul file viene condivisa da processi diversi
976 (vedi sez.~\ref{sec:file_sharing}). Il valore di
977 \param{offset} fa sempre riferimento all'inizio del file.
979 La funzione \func{pread} è disponibile anche in Linux, però diventa
980 accessibile solo attivando il supporto delle estensioni previste dalle
981 \textit{Single Unix Specification} con la definizione della macro:
983 #define _XOPEN_SOURCE 500
985 e si ricordi di definire questa macro prima dell'inclusione del file di
986 dichiarazioni \headfile{unistd.h}.
990 \subsection{Le funzioni per la scrittura}
991 \label{sec:file_write}
993 Una volta che un file è stato aperto (con il permesso in scrittura) si può
994 scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
995 \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
997 Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
999 \bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
1000 e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
1003 \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
1005 \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
1006 consentita dal filesystem o il limite per le dimensioni dei file del
1007 processo o su una posizione oltre il massimo consentito.
1008 \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
1009 chiuso in lettura; in questo caso viene anche generato il segnale
1010 \signal{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
1011 funzione ritorna questo errore.
1012 \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
1013 potuto scrivere qualsiasi dato.
1014 \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
1015 modalità \const{O\_NONBLOCK}.
1017 ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
1018 \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
1019 dipendenti dalla natura dell'oggetto connesso a \param{fd}.}
1022 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
1023 a partire dalla posizione corrente nel file e sposta automaticamente la
1024 posizione in avanti del numero di byte scritti. Se il file è aperto in
1025 modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
1026 alla fine del file. Lo standard POSIX richiede che i dati scritti siano
1027 immediatamente disponibili ad una \func{read} chiamata dopo che la
1028 \func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
1029 non è detto che tutti i filesystem supportino questa capacità.
1031 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
1032 Per i file ordinari il numero di byte scritti è sempre uguale a quello
1033 indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
1034 stesso comportamento di \func{read}.
1036 Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
1037 per scrivere alla posizione indicata senza modificare la posizione corrente
1038 nel file, il suo prototipo è:
1039 \begin{prototype}{unistd.h}
1040 {ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
1042 Cerca di scrivere sul file \param{fd}, a partire dalla posizione
1043 \param{offset}, \param{count} byte dal buffer \param{buf}.
1045 \bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
1046 $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
1047 visti per \func{write} e \func{lseek}.}
1049 \noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
1052 \section{Caratteristiche avanzate}
1053 \label{sec:file_adv_func}
1055 In questa sezione approfondiremo alcune delle caratteristiche più sottili
1056 della gestione file in un sistema unix-like, esaminando in dettaglio il
1057 comportamento delle funzioni base, inoltre tratteremo le funzioni che
1058 permettono di eseguire alcune operazioni avanzate con i file (il grosso
1059 dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
1062 \subsection{La condivisione dei files}
1063 \label{sec:file_sharing}
1065 In sez.~\ref{sec:file_fd} abbiamo descritto brevemente l'architettura
1066 dell'interfaccia con i file da parte di un processo, mostrando in
1067 fig.~\ref{fig:file_proc_file} le principali strutture usate dal kernel;
1068 esamineremo ora in dettaglio le conseguenze che questa architettura ha nei
1069 confronti dell'accesso allo stesso file da parte di processi diversi.
1071 \begin{figure}[!htb]
1073 \includegraphics[width=15cm]{img/filemultacc}
1074 \caption{Schema dell'accesso allo stesso file da parte di due processi
1076 \label{fig:file_mult_acc}
1079 Il primo caso è quello in cui due processi diversi aprono lo stesso file su
1080 disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
1081 situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
1082 processo avrà una sua voce nella \textit{file table} referenziata da un
1083 diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
1084 nella \itindex{file~table} \textit{file table} faranno però riferimento allo
1085 stesso \itindex{inode} inode su disco.
1087 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
1088 la sua modalità di accesso e versioni proprie di tutte le proprietà che
1089 vengono mantenute nella sua voce della \itindex{file~table} \textit{file
1090 table}. Questo ha conseguenze specifiche sugli effetti della possibile
1091 azione simultanea sullo stesso file, in particolare occorre tenere presente
1094 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
1095 \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
1096 scrittura eccede la dimensione corrente del file questo verrà esteso
1097 automaticamente con l'aggiornamento del campo \var{i\_size} \itindex{inode}
1099 \item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
1100 le volte che viene effettuata una scrittura la posizione corrente viene
1101 prima impostata alla dimensione corrente del file letta \itindex{inode}
1102 dall'inode. Dopo la scrittura il file viene automaticamente esteso.
1103 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
1104 \var{f\_pos} nella struttura \kstruct{file} della \itindex{file~table}
1105 \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
1106 si usa per porsi alla fine del file la posizione viene impostata leggendo la
1107 dimensione corrente \itindex{inode} dall'inode.
1110 \begin{figure}[!htb]
1112 \includegraphics[width=15cm]{img/fileshar}
1113 \caption{Schema dell'accesso ai file da parte di un processo figlio}
1114 \label{fig:file_acc_child}
1117 Il secondo caso è quello in cui due file descriptor di due processi diversi
1118 puntino alla stessa voce nella \itindex{file~table} \textit{file table};
1119 questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
1120 figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
1121 sez.~\ref{sec:proc_fork}). La situazione è illustrata in
1122 fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
1123 dello spazio di indirizzi del padre, riceverà anche una copia di
1124 \kstruct{file\_struct} e relativa tabella dei file aperti.
1126 In questo modo padre e figlio avranno gli stessi file descriptor che faranno
1127 riferimento alla stessa voce nella \textit{file table}, condividendo così la
1128 posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
1129 sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
1130 corrente nel file varierà per entrambi i processi (in quanto verrà modificato
1131 \var{f\_pos} che è lo stesso per entrambi).
1133 Si noti inoltre che anche i \itindex{file~status~flag} flag di stato del file
1134 (quelli impostati dall'argomento \param{flag} di \func{open}) essendo tenuti
1135 nella voce della \textit{file table}\footnote{per la precisione nel campo
1136 \var{f\_flags} di \kstruct{file}, vedi fig.~\ref{fig:kstruct_file}.},
1137 vengono in questo caso condivisi. Ai file però sono associati anche altri
1138 flag, dei quali l'unico usato al momento è \const{FD\_CLOEXEC}, detti
1139 \index{file~descriptor~flags} \textit{file descriptor flags}. Questi ultimi
1140 sono tenuti invece in \kstruct{file\_struct}, e perciò sono specifici di
1141 ciascun processo e non vengono modificati dalle azioni degli altri anche in
1142 caso di condivisione della stessa voce della \textit{file table}.
1146 \subsection{Operazioni atomiche con i file}
1147 \label{sec:file_atomic}
1149 Come si è visto in un sistema unix-like è sempre possibile per più processi
1150 accedere in contemporanea allo stesso file, e che le operazioni di lettura e
1151 scrittura possono essere fatte da ogni processo in maniera autonoma in base
1152 ad una posizione corrente nel file che è locale a ciascuno di essi.
1154 Se dal punto di vista della lettura dei dati questo non comporta nessun
1155 problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
1156 maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
1157 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
1158 utilizzare meccanismi di sincronizzazione più complessi (come il
1159 \itindex{file~locking} \textit{file locking}, che esamineremo in
1160 sez.~\ref{sec:file_locking}).
1162 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
1163 vari processi devono scrivere alla fine di un file (ad esempio un file di
1164 log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
1165 fine del file e poi scrivere può condurre ad una \itindex{race~condition}
1166 \textit{race condition}: infatti può succedere che un secondo processo scriva
1167 alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
1168 abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
1169 ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
1170 più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
1173 Il problema è che usare due \textit{system call} in successione non è
1174 un'operazione atomica; il problema è stato risolto introducendo la modalità
1175 \itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
1176 descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
1177 alla fine del file prima di effettuare la scrittura, e poi estende il file.
1178 Tutto questo avviene all'interno di una singola \textit{system call} (la
1179 \func{write}) che non essendo interrompibile da un altro processo costituisce
1180 un'operazione atomica.
1182 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
1183 creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
1184 esiste. In questo caso la sequenza logica porterebbe a verificare prima
1185 l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
1186 di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
1187 condition} da parte di un altro processo che crea lo stesso file fra il
1188 controllo e la creazione.
1190 Per questo motivo sono stati introdotti per \func{open} i due flag
1191 \const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
1192 dell'esistenza del file (con relativa uscita dalla funzione con un errore) e
1193 creazione in caso di assenza, diventa atomica essendo svolta tutta all'interno
1194 di una singola \textit{system call} (per i dettagli sull'uso di questa
1195 caratteristica si veda sez.~\ref{sec:ipc_file_lock}).
1198 \subsection{Le funzioni \func{sync} e \func{fsync}}
1199 \label{sec:file_sync}
1201 % TODO, aggiungere syncfs, introdotta con il 2.6.39
1203 Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
1204 sono in genere bufferizzate dal kernel, che provvede ad effettuarle in maniera
1205 asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
1206 secondo tempo rispetto al momento della esecuzione della \func{write}.
1208 Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
1209 sistema mette a disposizione delle funzioni che provvedono a forzare lo
1210 scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
1211 questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
1212 l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
1213 ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
1214 scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
1216 \begin{prototype}{unistd.h}{int sync(void)}
1218 Sincronizza il buffer della cache dei file col disco.
1220 \bodydesc{La funzione ritorna sempre zero.}
1222 \noindent i vari standard prevedono che la funzione si limiti a far partire
1223 le operazioni, ritornando immediatamente; in Linux (dal kernel 1.3.20) invece
1224 la funzione aspetta la conclusione delle operazioni di sincronizzazione del
1227 La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
1228 esplicitamente lo scarico dei dati su disco, o dal demone di sistema
1229 \cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
1230 valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
1231 in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
1232 partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
1233 tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
1234 può essere controllato attraverso il file \sysctlfile{vm/bdflush} (per
1235 il significato dei valori si può leggere la documentazione allegata al kernel
1236 in \file{Documentation/sysctl/vm.txt}).
1238 Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
1239 sicuri che i dati di un database sono stati registrati su disco) si possono
1240 usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
1243 \funcdecl{int fsync(int fd)}
1244 Sincronizza dati e meta-dati del file \param{fd}
1245 \funcdecl{int fdatasync(int fd)}
1246 Sincronizza i dati del file \param{fd}.
1248 \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
1249 errore, nel qual caso \var{errno} assume i valori:
1251 \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
1252 che non supporta la sincronizzazione.
1254 ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
1257 Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
1258 file specificato, ed attendono fino alla conclusione delle operazioni;
1259 \func{fsync} forza anche la sincronizzazione dei meta-dati del file (che
1260 riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
1261 altri dati contenuti \itindex{inode} nell'inode che si leggono con \func{fstat},
1262 come i tempi del file).
1264 Si tenga presente che questo non comporta la sincronizzazione della
1265 directory che contiene il file (e scrittura della relativa voce su
1266 disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
1267 il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
1268 il kernel provvede anche alla sincronizzazione automatica delle voci
1272 \subsection{Le funzioni \func{dup} e \func{dup2}}
1273 \label{sec:file_dup}
1275 Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
1276 condivida gli stessi file descriptor del padre; è possibile però ottenere un
1277 comportamento analogo all'interno di uno stesso processo \textit{duplicando}
1278 un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
1280 \begin{prototype}{unistd.h}{int dup(int oldfd)}
1281 Crea una copia del file descriptor \param{oldfd}.
1283 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
1284 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
1287 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
1288 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
1293 La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
1294 file descriptor è una copia esatta del precedente ed entrambi possono essere
1295 interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
1296 può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
1297 semplicemente quello di copiare il valore nella struttura
1298 \kstruct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
1299 alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
1300 file descriptor è \textsl{duplicato}, da cui il nome della funzione.
1302 \begin{figure}[!htb]
1303 \centering \includegraphics[width=14cm]{img/filedup}
1304 \caption{Schema dell'accesso ai file duplicati}
1305 \label{fig:file_dup}
1308 Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
1309 duplicati condivideranno eventuali lock, \textit{file status flag}, e
1310 posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
1311 posizione su uno dei due file descriptor, essa risulterà modificata anche
1312 sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
1313 della \textit{file table} a cui entrambi fanno riferimento). L'unica
1314 differenza fra due file descriptor duplicati è che ciascuno avrà il suo
1315 \textit{file descriptor flag}; a questo proposito va specificato che nel caso
1316 di \func{dup} il flag di \textit{close-on-exec} \itindex{close-on-exec} (vedi
1317 sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
1320 L'uso principale di questa funzione è per la redirezione dell'input e
1321 dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
1322 diventa così possibile associare un file (o una pipe) allo standard input o
1323 allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
1324 quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
1325 il file che si vuole sostituire, cosicché il suo file descriptor possa esser
1326 restituito alla chiamata di \func{dup}, come primo file descriptor
1329 Dato che questa è l'operazione più comune, è prevista una diversa versione
1330 della funzione, \funcd{dup2}, che permette di specificare esplicitamente
1331 qual è il valore di file descriptor che si vuole avere come duplicato; il suo
1333 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
1335 Rende \param{newfd} una copia del file descriptor \param{oldfd}.
1337 \bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
1338 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1340 \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
1341 un valore fuori dall'intervallo consentito per i file descriptor.
1342 \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
1346 \noindent e qualora il file descriptor \param{newfd} sia già aperto (come
1347 avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
1348 sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
1349 allo stesso valore per il file descriptor).
1351 La duplicazione dei file descriptor può essere effettuata anche usando la
1352 funzione di controllo dei file \func{fcntl} (che esamineremo in
1353 sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
1354 la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
1355 \param{newfd} diventa equivalente a \func{dup}.
1357 La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
1358 diversi codici di errore.} è che \func{dup2} chiude il file descriptor
1359 \param{newfd} se questo è già aperto, garantendo che la duplicazione sia
1360 effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
1361 file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
1362 \param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
1366 \subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
1367 \label{sec:file_openat}
1369 \itindbeg{at-functions}
1371 Un problema che si pone con l'uso della funzione \func{open}, così come per
1372 molte altre funzioni che accettano come argomenti dei
1373 \itindsub{pathname}{relativo} \textit{pathname} relativi, è che, quando un
1374 \textit{pathname} relativo non fa riferimento alla \index{directory~di~lavoro}
1375 directory di lavoro corrente, è possibile che alcuni dei suoi componenti
1376 vengano modificati in parallelo alla chiamata a \func{open}, e questo lascia
1377 aperta la possibilità di una \itindex{race~condition} \textit{race condition}.
1379 Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
1380 corrente è una proprietà del singolo processo; questo significa che quando si
1381 lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
1382 ma esistono molti casi in cui sarebbe invece utile che ogni singolo
1383 \itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
1384 directory di lavoro.
1386 Per risolvere questi problemi, riprendendo una interfaccia già presente in
1387 Solaris, a fianco delle normali funzioni che operano sui file (come
1388 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
1389 funzioni, dette anche funzioni ``\textit{at}'' in quanto contraddistinte dal
1390 suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
1391 altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
1392 relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
1393 proposta dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
1394 corrispondenti \textit{system call} sono state inserite nel kernel ufficiale
1395 a partire dalla versione 2.6.16, in precedenza era disponibile una
1396 emulazione che, sia pure con prestazioni inferiori, funzionava facendo
1397 ricorso all'uso del filesystem \textit{proc} con l'apertura del file
1398 attraverso il riferimento a \textit{pathname} del tipo di
1399 \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
1400 siano presenti negli standard tradizionali esse sono state adottate da vari
1401 Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
1402 essere incluse nella recente revisione (la POSIX.1-2008) dello standard
1403 POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
1404 definire la macro \macro{\_ATFILE\_SOURCE}.
1406 L'uso di queste funzioni prevede una apertura iniziale della directory che
1407 sarà la base della risoluzione dei \itindsub{pathname}{relativo}
1408 \textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
1409 passare il relativo file descriptor alle varie funzioni che useranno quella
1410 directory come punto di partenza per la risoluzione.\footnote{in questo modo,
1411 anche quando si lavora con i \itindex{thread} \textit{thread}, si può
1412 mantenere una \index{directory~di~lavoro} directory di lavoro diversa per
1415 Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
1416 \textit{race condition}, consente anche di ottenere aumenti di prestazioni
1417 significativi quando si devono eseguire molte operazioni su sezioni
1418 dell'albero dei file che prevedono delle gerarchie di sottodirectory molto
1419 profonde; infatti in questo caso basta eseguire la risoluzione del
1420 \textit{pathname} della directory di partenza una sola volta (nell'apertura
1421 iniziale) e non tutte le volte che si deve accedere a ciascun file che essa
1424 La sintassi generale di queste nuove funzioni è che esse prevedono come primo
1425 argomento il file descriptor della directory da usare come base, mentre gli
1426 argomenti successivi restano identici a quelli della corrispondente funzione
1427 ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
1431 \funcdecl{int openat(int dirfd, const char *pathname, int flags)}
1432 \funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
1435 Apre un file usando come directory di \index{directory~di~lavoro} lavoro
1436 corrente \param{dirfd}.
1438 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1439 errore di \func{open}, ed in più:
1441 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1442 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1443 \textit{pathname} relativo, ma
1444 \param{dirfd} fa riferimento ad un file.
1448 Il comportamento delle nuove funzioni è del tutto analogo a quello delle
1449 corrispettive classiche, con la sola eccezione del fatto che se fra i loro
1450 argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
1451 relativo questo sarà risolto rispetto alla directory indicata
1452 da \param{dirfd}; qualora invece si usi un \itindsub{pathname}{assoluto}
1453 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
1455 \param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
1456 come le altre costanti \texttt{AT\_*}, è definita in \headfile{fcntl.h},
1457 pertanto se la si vuole usare occorrerà includere comunque questo file,
1458 anche per le funzioni che non sono definite in esso.} la risoluzione sarà
1459 effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
1460 corrente del processo.
1462 Così come il comportamento, anche i valori di ritorno e le condizioni di
1463 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
1464 errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
1465 particolare si avrà un errore di \errcode{EBADF} se esso non è un file
1466 descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
1467 riferimento ad una directory.\footnote{tranne il caso in cui si sia
1468 specificato un \itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel
1469 qual caso, come detto, il valore di \param{dirfd} sarà completamente
1472 In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
1473 con questa nuova interfaccia, con a fianco la corrispondente funzione
1474 classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
1475 funzioni \func{utimes} e \func{lutimes} non sono propriamente le
1476 corrispondenti di \func{utimensat}, dato che questa ha una maggiore
1477 precisione nella indicazione dei tempi dei file.} La gran parte di queste
1478 seguono la convenzione appena vista per \func{openat}, in cui agli argomenti
1479 della corrispondente funzione classica viene anteposto
1480 l'argomento \param{dirfd}.\footnote{non staremo pertanto a riportarle una per
1481 una.} Per una parte di queste, indicate dal contenuto della omonima colonna
1482 di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
1483 prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
1488 \begin{tabular}[c]{|l|c|l|}
1490 \textbf{Funzione} &\textbf{Flags} &\textbf{Corrispondente} \\
1493 \func{faccessat} &$\bullet$&\func{access} \\
1494 \func{fchmodat} &$\bullet$&\func{chmod} \\
1495 \func{fchownat} &$\bullet$&\func{chown},\func{lchown}\\
1496 \func{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
1497 \func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
1498 \func{linkat} &$\bullet$\footnotemark&\func{link} \\
1499 \funcm{mkdirat} & -- &\func{mkdir} \\
1500 \funcm{mknodat} & -- &\func{mknod} \\
1501 \func{openat} & -- &\func{open} \\
1502 \funcm{readlinkat}& -- &\func{readlink}\\
1503 \funcm{renameat} & -- &\func{rename} \\
1504 \funcm{symlinkat}& -- &\func{symlink} \\
1505 \func{unlinkat} &$\bullet$&\func{unlink},\func{rmdir} \\
1506 \funcm{mkfifoat} & -- &\func{mkfifo} \\
1509 \caption{Corrispondenze fra le nuove funzioni ``\textit{at}'' e le
1510 corrispettive funzioni classiche.}
1511 \label{tab:file_atfunc_corr}
1514 \footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
1515 utilizzabile solo a partire dal kernel 2.6.18.}
1517 % TODO manca prototipo di fchmodat, verificare se metterlo o metter menzione
1518 % TODO manca prototipo di fstatat, verificare se metterlo o metter menzione
1519 % TODO manca prototipo di linkat, verificare se metterlo o metter menzione
1520 % TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
1522 Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
1523 \funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
1524 un meccanismo con cui modificarne il comportamento nel caso si stia operando
1525 su un collegamento simbolico, così da poter scegliere se far agire la funzione
1526 direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
1527 casi esso può fornire ulteriori indicazioni per modificare il comportamento
1528 delle funzioni, \param{flags} deve comunque essere passato come maschera
1529 binaria, ed impostato usando i valori delle appropriate costanti
1530 \texttt{AT\_*}, definite in \headfile{fcntl.h}.
1532 Come esempio di questo secondo tipo di funzioni possiamo considerare
1533 \funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
1534 che \func{lchown}; il suo prototipo è:
1536 \headdecl{unistd.h} \headdecl{fcntl.h}
1538 \funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
1541 Modifica la proprietà di un file.
1543 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1544 errore di \func{chown}, ed in più:
1546 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1547 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1548 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1549 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1553 In questo caso il valore di \param{flags} stabilisce il comportamento della
1554 funzione quando la si applica ad un collegamento simbolico, e l'unico valore
1555 utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è
1556 definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
1557 collegamenti simbolici, essendo questo però il comportamento adottato per un
1558 valore nullo di \param{flags} questo valore non viene mai usato.} che se
1559 impostato indica alla funzione di non eseguire la dereferenziazione di un
1560 eventuale collegamento simbolico, facendo comportare \func{fchownat} come
1561 \func{lchown} invece che come \func{chown}.
1563 Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
1564 solo due funzioni possono usare l'argomento \param{flags} con valori diversi
1565 da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
1569 \funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
1571 Controlla i permessi di accesso.
1573 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1574 errore di \func{access}, ed in più:
1576 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1577 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1578 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1579 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1583 La funzione esegue lo stesso controllo di accesso effettuabile con
1584 \func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
1585 il comportamento rispetto a quello ordinario di \func{access}. In questo caso
1586 esso può essere specificato come maschera binaria di due valori:
1587 \begin{basedescript}{\desclabelwidth{3.0cm}}
1588 \item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
1589 dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
1590 comportamento di default, che riprende quello di \func{access}).
1591 \item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
1592 la dereferenziazione dei collegamenti simbolici, effettuando il controllo
1593 dei permessi direttamente sugli stessi.
1596 La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
1597 argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
1598 comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
1602 \funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
1604 Rimuove una voce da una directory.
1606 \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
1607 errore di \func{unlink} o di \func{rmdir} a seconda del valore di
1608 \param{flags}, ed in più:
1610 \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
1611 \item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
1612 \item[\errcode{ENOTDIR}] \param{pathname} è un \itindsub{pathname}{relativo}
1613 \textit{pathname} relativo, ma \param{dirfd} fa riferimento ad un file.
1617 Di default il comportamento di \func{unlinkat} è equivalente a quello che
1618 avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
1619 in cui questo è una directory, se però si imposta \param{flags} al valore di
1620 \const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
1621 essendo questo l'unico flag disponibile per questa funzione, lo si può
1622 assegnare direttamente.} essa si comporterà come \func{rmdir}, in tal
1623 caso \param{pathname} deve essere una directory, che sarà rimossa qualora
1626 \itindend{at-functions}
1629 % TODO manca prototipo e motivazione di fexecve, da trattare qui in quanto
1630 % inserita nello stesso standard e da usare con openat, vedi
1631 % http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
1636 \subsection{La funzione \func{fcntl}}
1637 \label{sec:file_fcntl}
1639 Oltre alle operazioni base esaminate in sez.~\ref{sec:file_unix_interface}
1640 esistono tutta una serie di operazioni ausiliarie che è possibile eseguire su
1641 un file descriptor, che non riguardano la normale lettura e scrittura di dati,
1642 ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori
1643 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
1644 gestiscono con questa funzione varie modalità di I/O asincrono (vedi
1645 sez.~\ref{sec:file_asyncronous_operation}) e il \itindex{file~locking}
1646 \textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
1648 Per queste operazioni di manipolazione e di controllo delle varie proprietà e
1649 caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
1654 \funcdecl{int fcntl(int fd, int cmd)}
1655 \funcdecl{int fcntl(int fd, int cmd, long arg)}
1656 \funcdecl{int fcntl(int fd, int cmd, struct flock * lock)}
1657 Esegue una delle possibili operazioni specificate da \param{cmd}
1658 sul file \param{fd}.
1660 \bodydesc{La funzione ha valori di ritorno diversi a seconda
1661 dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
1662 il codice dell'errore è restituito nella variabile \var{errno}; i codici
1663 possibili dipendono dal tipo di operazione, l'unico valido in generale è:
1665 \item[\errcode{EBADF}] \param{fd} non è un file aperto.
1670 Il primo argomento della funzione è sempre il numero di file descriptor
1671 \var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
1672 numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
1673 sono determinati dal valore dell'argomento \param{cmd} che in sostanza
1674 corrisponde all'esecuzione di un determinato \textsl{comando}; in
1675 sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
1676 per la duplicazione dei file descriptor, una lista di tutti i possibili valori
1677 per \var{cmd} è riportata di seguito:
1678 \begin{basedescript}{\desclabelwidth{2.0cm}}
1679 \item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
1680 maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
1681 nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
1682 errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
1683 del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
1684 massimo numero di descrittori consentito.
1685 \item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
1686 valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
1687 \itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
1688 \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
1689 esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
1690 valore nullo in caso di successo e $-1$ in caso di errore.
1691 \item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
1692 \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
1693 file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
1694 (il comportamento predefinito) restano aperti.
1695 \item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
1696 caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
1697 bit impostati da \func{open} all'apertura del file che vengono memorizzati
1698 (quelli riportati nella prima e terza sezione di
1699 tab.~\ref{tab:file_open_flags}).
1700 % TODO toglire riferimeto a tabella flag e mettere altro
1702 \item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
1703 specificato da \param{arg}, ritorna un valore nullo in caso di successo o
1704 $-1$ in caso di errore. Possono essere impostati solo i bit riportati nella
1705 terza sezione di tab.~\ref{tab:file_open_flags}.\footnote{la pagina di
1706 manuale riporta come impostabili solo \const{O\_APPEND},
1707 \const{O\_NONBLOCK} e \const{O\_ASYNC}.}
1708 % TODO toglire riferimeto a tabella flag e mettere altro
1710 \item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
1711 \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
1712 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
1713 funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
1714 \item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
1715 specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
1716 qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
1717 \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
1718 nullo. Questa funzionalità è trattata in dettaglio in
1719 sez.~\ref{sec:file_posix_lock}.
1720 \item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
1721 la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
1722 l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
1723 imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
1724 nullo. Questa funzionalità è trattata in dettaglio in
1725 sez.~\ref{sec:file_posix_lock}.
1726 \item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o
1727 l'identificatore del \itindex{process~group} \textit{process
1728 group}\footnote{i \itindex{process~group} \textit{process group} sono
1729 (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
1730 controllo di sessione; a ciascuno di essi è associato un identificatore
1731 (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione
1732 dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo
1733 impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
1734 descriptor \param{fd}\footnote{il segnale viene usato sia per il
1735 \textit{Signal Drive I/O}, che tratteremo in
1736 sez.~\ref{sec:file_asyncronous_operation}, e dai vari meccanismi di
1737 notifica asincrona, che tratteremo in
1738 sez.~\ref{sec:file_asyncronous_lease}.} e \signal{SIGURG} per la notifica
1739 dei dati urgenti di un socket.\footnote{vedi
1740 sez.~\ref{sec:TCP_urgent_data}.} Nel caso di un \textit{process group}
1741 viene restituito un valore negativo il cui valore assoluto corrisponde
1742 all'identificatore del \itindex{process~group} \textit{process group}. In
1743 caso di errore viene restituito $-1$.
1744 \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
1745 l'identificatore del processo o del \itindex{process~group} \textit{process
1746 group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
1747 eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
1748 caso di successo o $-1$ in caso di errore. Come per \const{F\_GETOWN}, per
1749 impostare un \itindex{process~group} \textit{process group} si deve usare
1750 per \param{arg} un valore negativo, il cui valore assoluto corrisponde
1751 all'identificatore del \itindex{process~group} \textit{process group}.
1752 \item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
1753 sono dati disponibili in ingresso su un file descriptor aperto ed impostato
1754 per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
1755 indica il valore predefinito (che è \signal{SIGIO}), un valore diverso da
1756 zero indica il segnale richiesto, (che può essere anche lo stesso
1757 \signal{SIGIO}). In caso di errore ritorna $-1$.
1758 \item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
1759 possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
1760 ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
1761 valore zero indica di usare il segnale predefinito, \signal{SIGIO}. Un altro
1762 valore diverso da zero (compreso lo stesso \signal{SIGIO}) specifica il
1763 segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
1764 installato il gestore del segnale come \var{sa\_sigaction} usando
1765 \const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
1766 disponibili al gestore informazioni ulteriori riguardo il file che ha
1767 generato il segnale attraverso i valori restituiti in \struct{siginfo\_t}
1768 (come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
1769 \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
1771 \item[\const{F\_SETLEASE}] imposta o rimuove un \itindex{file~lease}
1772 \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
1773 Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
1774 processo che detiene un \textit{lease} su un file riceve una notifica
1775 qualora un altro processo cerca di eseguire una \func{open} o una
1776 \func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
1777 valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
1778 valore nullo in caso di successo o $-1$ in caso di errore. Questa
1779 funzionalità avanzata è trattata in dettaglio in
1780 sez.~\ref{sec:file_asyncronous_lease}.
1781 \item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
1782 \textit{file lease} che il processo detiene nei confronti del file
1783 descriptor \var{fd} o $-1$ in caso di errore. Con questo comando il terzo
1784 argomento può essere omesso. Questa funzionalità avanzata è trattata in
1785 dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
1786 \item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
1787 riportata al processo chiamante, tramite il segnale \signal{SIGIO} (o altro
1788 segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
1789 direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
1790 in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
1791 di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
1792 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
1795 La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
1796 poter essere affrontate in tutti i loro aspetti a questo punto; saranno
1797 pertanto riprese più avanti quando affronteremo le problematiche ad esse
1798 relative. In particolare le tematiche relative all'I/O asincrono e ai vari
1799 meccanismi di notifica saranno trattate in maniera esaustiva in
1800 sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
1801 \itindex{file~locking} \textit{file locking} saranno esaminate in
1802 sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
1803 trattato in sez.~\ref{sec:sock_ctrl_func}.
1805 Si tenga presente infine che quando si usa la funzione per determinare le
1806 modalità di accesso con cui è stato aperto il file (attraverso l'uso del
1807 comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
1808 \textit{file status flag} che si è ottenuto. Infatti la definizione corrente
1809 di quest'ultimo non assegna bit separati alle tre diverse modalità
1810 \const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
1811 queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
1812 motivo il valore della modalità di accesso corrente si ottiene eseguendo un
1813 AND binario del valore di ritorno di \func{fcntl} con la maschera
1814 \const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
1815 bit di accesso dal \textit{file status flag}.
1819 \subsection{La funzione \func{ioctl}}
1820 \label{sec:file_ioctl}
1822 Benché il concetto di \textit{everything is a file} si sia dimostrato molto
1823 valido anche per l'interazione con i dispositivi più vari, fornendo una
1824 interfaccia che permette di interagire con essi tramite le stesse funzioni
1825 usate per i normali file di dati, esisteranno sempre caratteristiche
1826 peculiari, specifiche dell'hardware e della funzionalità che ciascun
1827 dispositivo può provvedere, che non possono venire comprese in questa
1828 interfaccia astratta (un caso tipico è l'impostazione della velocità di una
1829 porta seriale, o le dimensioni di un framebuffer).
1831 Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
1832 di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
1833 specifiche di ogni dispositivo particolare, usando come riferimento il solito
1834 file descriptor. Il prototipo di questa funzione è:
1835 \begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
1837 Esegue l'operazione di controllo specificata da \param{request} sul file
1838 descriptor \param{fd}.
1840 \bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
1841 operazioni usano però il valore di ritorno per restituire informazioni. In
1842 caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
1845 \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
1846 dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
1847 riferimento \param{fd}.
1848 \item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
1851 ed inoltre \errval{EBADF} e \errval{EFAULT}.}
1854 La funzione serve in sostanza come meccanismo generico per fare tutte quelle
1855 operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
1856 file e che non è possibile effettuare con le funzioni esaminate finora. La
1857 funzione richiede che si passi come primo argomento un file descriptor
1858 regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
1859 il valore dell'argomento \param{request}. Il terzo argomento dipende
1860 dall'operazione prescelta; tradizionalmente è specificato come \code{char *
1861 argp}, da intendersi come puntatore ad un area di memoria
1862 generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
1863 non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
1864 essere omesso, e per altre è un semplice intero.
1866 Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
1867 errore, ma per alcune operazione il valore di ritorno, che nel caso viene
1868 impostato ad un valore positivo, può essere utilizzato come parametro di
1869 uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
1872 Data la genericità dell'interfaccia non è possibile classificare in maniera
1873 sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
1874 elenco di alcuni esempi di esse è il seguente:
1876 \item il cambiamento dei font di un terminale.
1877 \item l'esecuzione di una traccia audio di un CDROM.
1878 \item i comandi di avanti veloce e riavvolgimento di un nastro.
1879 \item il comando di espulsione di un dispositivo rimovibile.
1880 \item l'impostazione della velocità trasmissione di una linea seriale.
1881 \item l'impostazione della frequenza e della durata dei suoni emessi dallo
1883 \item l'impostazione degli attributi dei file su un filesystem
1884 ext2.\footnote{i comandi \texttt{lsattr} e \texttt{chattr} fanno questo con
1885 delle \func{ioctl} dedicate, usabili solo su questo filesystem e derivati
1886 successivi (come ext3).}
1889 In generale ogni dispositivo ha un suo insieme di operazioni specifiche
1890 effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
1891 file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
1892 fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
1893 opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
1894 un apposito \textit{magic number} per distinguere ciascun dispositivo nella
1895 definizione delle macro da usare per \param{request}, in modo da essere
1896 sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
1897 causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
1898 una trattazione dettagliata dell'argomento.} così che la richiesta di
1899 operazioni relative ad altri dispositivi usualmente provoca il ritorno della
1900 funzione con una condizione di errore, in alcuni casi, relativi a valori
1901 assegnati prima che questa differenziazione diventasse pratica corrente, si
1902 potrebbero usare valori validi anche per il dispositivo corrente, con effetti
1903 imprevedibili o indesiderati.
1905 Data la assoluta specificità della funzione, il cui comportamento varia da
1906 dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
1907 sommaria delle sue caratteristiche; torneremo ad esaminare in
1908 seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
1909 sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
1910 esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
1911 quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
1912 operazioni che sono predefinite per qualunque file,\footnote{in particolare
1913 queste operazioni sono definite nel kernel a livello generale, e vengono
1914 sempre interpretate per prime, per cui, come illustrato in \cite{LinDevDri},
1915 eventuali operazioni specifiche che usino lo stesso valore verrebbero
1916 ignorate.} caratterizzate dal prefisso \texttt{FIO}:
1917 \begin{basedescript}{\desclabelwidth{2.0cm}}
1918 \item[\const{FIOCLEX}] imposta il flag di \itindex{close-on-exec}
1919 \textit{close-on-exec} sul file, in questo caso, essendo usata come
1920 operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
1921 eventuale valore viene ignorato.
1922 \item[\const{FIONCLEX}] cancella il flag di \itindex{close-on-exec}
1923 \textit{close-on-exec} sul file, in questo caso, essendo usata come
1924 operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
1925 eventuale valore viene ignorato.
1926 \item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
1927 file (vedi sez.~\ref{sec:file_asyncronous_operation}); il terzo argomento
1928 deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
1929 che contiene un valore logico (un valore nullo disabilita, un valore non
1931 \item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
1932 bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
1933 tipo \texttt{const int *}) che contiene un valore logico (un valore nullo
1934 disabilita, un valore non nullo abilita).
1935 \item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
1936 \signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
1937 essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
1938 valore specifica il PID del processo.
1939 \item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
1940 \signal{SIGURG} e \signal{SIGIO} generati sul file; il terzo argomento deve
1941 essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
1942 scritto il PID del processo.
1943 \item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
1944 file descriptor;\footnote{questa operazione è disponibile solo su alcuni
1945 file descriptor, in particolare sui socket (vedi
1946 sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
1947 (vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
1948 puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
1950 \item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
1951 directory, mentre se applicata ad un dispositivo fallisce con un errore di
1952 \errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
1953 (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
1956 % TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
1958 Si noti però come la gran parte di queste operazioni specifiche dei file (per
1959 essere precisi le prime sei dell'elenco) siano effettuabili in maniera
1960 generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
1961 molto simili e la presenza di questa sovrapposizione è principalmente dovuta
1962 al fatto che alle origini di Unix i progettisti considerarono che era
1963 necessario trattare diversamente rispetto alle operazione di controllo delle
1964 modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
1965 \func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
1966 usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
1967 l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
1968 ma le due funzioni sono rimaste.
1970 % TODO trovare qualche posto per la eventuale documentazione delle seguenti
1971 % (bassa/bassissima priorità)
1972 % EXT4_IOC_MOVE_EXT (dal 2.6.31)
1979 \section{L'interfaccia standard ANSI C}
1980 \label{sec:files_std_interface}
1983 Come visto in sez.~\ref{sec:file_unix_interface} le operazioni di I/O sui file
1984 sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
1985 direttamente alle \textit{system call} messe a disposizione dal kernel.
1987 Questa interfaccia però non provvede le funzionalità previste dallo standard
1988 ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
1989 queste, insieme alle altre funzioni definite dallo standard, vengono a
1990 costituire il nucleo\footnote{queste funzioni sono state implementate la prima
1991 volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente
1992 immutate.} delle \acr{glibc}.
1995 Esamineremo in questa sezione le funzioni base dell'interfaccia degli
1996 \textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
1997 file descriptor. In particolare vedremo come aprire, leggere, scrivere e
1998 cambiare la posizione corrente in uno \textit{stream}.
2001 \subsection{I \textit{file stream}}
2002 \label{sec:file_stream}
2004 \itindbeg{file~stream}
2006 Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
2007 basso livello, che non provvede nessuna forma di formattazione dei dati e
2008 nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
2010 In \cite{APUE} Stevens descrive una serie di test sull'influenza delle
2011 dimensioni del blocco di dati (l'argomento \param{buf} di \func{read} e
2012 \func{write}) nell'efficienza nelle operazioni di I/O con i file descriptor,
2013 evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni
2014 del buffer dei dati pari a quelle dei blocchi del filesystem (il valore dato
2015 dal campo \var{st\_blksize} di \struct{stat}), che di norma corrispondono alle
2016 dimensioni dei settori fisici in cui è suddiviso il disco.
2018 Se il programmatore non si cura di effettuare le operazioni in blocchi di
2019 dimensioni adeguate, le prestazioni sono inferiori. La caratteristica
2020 principale dell'interfaccia degli \textit{stream} è che essa provvede da sola
2021 alla gestione dei dettagli della bufferizzazione e all'esecuzione delle
2022 operazioni di lettura e scrittura in blocchi di dimensioni appropriate
2023 all'ottenimento della massima efficienza.
2025 Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
2026 \textit{file stream}, dato che non è più necessario doversi preoccupare
2027 dei dettagli della comunicazione con il tipo di hardware sottostante
2028 (come nel caso della dimensione dei blocchi del filesystem), ed un file
2029 può essere sempre considerato come composto da un flusso continuo (da
2030 cui il nome \textit{stream}) di dati.
2032 A parte i dettagli legati alla gestione delle operazioni di lettura e
2033 scrittura (sia per quel che riguarda la bufferizzazione, che le
2034 formattazioni), i \textit{file stream} restano del tutto equivalenti ai file
2035 descriptor (sui quali sono basati), ed in particolare continua a valere quanto
2036 visto in sez.~\ref{sec:file_sharing} a proposito dell'accesso condiviso ed in
2037 sez.~\ref{sec:file_access_control} per il controllo di accesso.
2039 \itindend{file~stream}
2042 \subsection{Gli oggetti \type{FILE}}
2043 \label{sec:file_FILE}
2046 Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
2047 è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
2048 libreria e contengono tutte le informazioni necessarie a gestire le operazioni
2049 sugli \textit{stream}, come la posizione corrente, lo stato del buffer e degli
2050 indicatori di stato e di fine del file.
2052 Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
2053 queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
2054 usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa
2055 (tanto che in certi casi il termine di puntatore a file è diventato sinonimo
2056 di \textit{stream}). Tutte le funzioni della libreria che operano sui file
2057 accettano come argomenti solo variabili di questo tipo, che diventa
2058 accessibile includendo l'header file \headfile{stdio.h}.
2061 \subsection{Gli \textit{stream standard}}
2062 \label{sec:file_std_stream}
2064 Ai tre file descriptor standard (vedi tab.~\ref{tab:file_std_files}) aperti
2065 per ogni processo, corrispondono altrettanti \textit{stream}, che
2066 rappresentano i canali standard di input/output prestabiliti; anche questi tre
2067 \textit{stream} sono identificabili attraverso dei nomi simbolici definiti
2068 nell'header \headfile{stdio.h} che sono:
2070 \begin{basedescript}{\desclabelwidth{3.0cm}}
2071 \item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
2072 stream} da cui il processo riceve ordinariamente i dati in
2073 ingresso. Normalmente è associato dalla shell all'input del terminale e
2074 prende i caratteri dalla tastiera.
2075 \item[\var{FILE *stdout}] Lo \textit{standard output} cioè il \textit{file
2076 stream} su cui il processo invia ordinariamente i dati in
2077 uscita. Normalmente è associato dalla shell all'output del terminale e
2078 scrive sullo schermo.
2079 \item[\var{FILE *stderr}] Lo \textit{standard error} cioè il \textit{file
2080 stream} su cui il processo è supposto inviare i messaggi di
2081 errore. Normalmente anch'esso è associato dalla shell all'output del
2082 terminale e scrive sullo schermo.
2085 Nella \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
2086 tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
2087 tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
2088 programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
2089 in altri sistemi queste variabili possono essere definite da macro, e se si
2090 hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
2091 usare la funzione \func{freopen}.
2094 \subsection{Le modalità di bufferizzazione}
2095 \label{sec:file_buffering}
2097 La bufferizzazione è una delle caratteristiche principali dell'interfaccia
2098 degli \textit{stream}; lo scopo è quello di ridurre al minimo il numero di
2099 \textit{system call} (\func{read} o \func{write}) eseguite nelle operazioni di
2100 input/output. Questa funzionalità è assicurata automaticamente dalla libreria,
2101 ma costituisce anche uno degli aspetti più comunemente fraintesi, in
2102 particolare per quello che riguarda l'aspetto della scrittura dei dati sul
2105 I caratteri che vengono scritti su di uno \textit{stream} normalmente vengono
2106 accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione
2107 viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
2108 inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
2109 maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene
2110 anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
2111 sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
2112 inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura
2113 invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da
2114 parte di un altro processo) si potranno vedere solo le parti effettivamente
2115 scritte, e non quelle ancora presenti nel buffer.
2117 Per lo stesso motivo, in tutte le situazioni in cui si sta facendo
2118 dell'input/output interattivo, bisognerà tenere presente le caratteristiche
2119 delle operazioni di scaricamento dei dati, poiché non è detto che ad una
2120 scrittura sullo \textit{stream} corrisponda una immediata scrittura sul
2121 dispositivo (la cosa è particolarmente evidente quando con le operazioni di
2122 input/output su terminale).
2124 Per rispondere ad esigenze diverse, lo standard definisce tre distinte
2125 modalità in cui può essere eseguita la bufferizzazione, delle quali
2126 occorre essere ben consapevoli, specie in caso di lettura e scrittura da
2127 dispositivi interattivi:
2129 \item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
2130 caratteri vengono trasmessi direttamente al file non appena possibile
2131 (effettuando immediatamente una \func{write}).
2132 \item \textit{line buffered}: in questo caso i caratteri vengono
2133 normalmente trasmessi al file in blocco ogni volta che viene
2134 incontrato un carattere di \textit{newline} (il carattere ASCII
2136 \item \textit{fully buffered}: in questo caso i caratteri vengono
2137 trasmessi da e verso il file in blocchi di dimensione opportuna.
2140 Lo standard ANSI C specifica inoltre che lo standard output e lo
2141 standard input siano aperti in modalità \textit{fully buffered} quando
2142 non fanno riferimento ad un dispositivo interattivo, e che lo standard
2143 error non sia mai aperto in modalità \textit{fully buffered}.
2145 Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
2146 ancora più precisa, e cioè impone che lo standard error sia sempre
2147 \textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
2148 rapidamente possibile) e che standard input e standard output siano aperti in
2149 modalità \textit{line buffered} quando sono associati ad un terminale (od
2150 altro dispositivo interattivo) ed in modalità \textit{fully buffered}
2153 Il comportamento specificato per standard input e standard output vale anche
2154 per tutti i nuovi \textit{stream} aperti da un processo; la selezione comunque
2155 avviene automaticamente, e la libreria apre lo \textit{stream} nella modalità
2156 più opportuna a seconda del file o del dispositivo scelto.
2158 La modalità \textit{line buffered} è quella che necessita di maggiori
2159 chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
2160 accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
2161 alla ricezione di un carattere di \textsl{a capo} (\textit{newline}); questo
2162 non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
2163 dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
2164 anche prima che sia stato inviato un carattere di \textit{newline}.
2166 Un secondo punto da tenere presente, particolarmente quando si ha a che fare
2167 con I/O interattivo, è che quando si effettua una lettura da uno
2168 \textit{stream} che comporta l'accesso al kernel\footnote{questo vuol dire che
2169 lo \textit{stream} da cui si legge è in modalità \textit{unbuffered}.} viene
2170 anche eseguito lo scarico di tutti i buffer degli \textit{stream} in
2173 In sez.~\ref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
2174 opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
2180 \subsection{Apertura e chiusura di uno \textit{stream}}
2181 \label{sec:file_fopen}
2183 Le funzioni che si possono usare per aprire uno \textit{stream} sono solo tre:
2184 \funcd{fopen}, \funcd{fdopen} e \funcd{freopen},\footnote{\func{fopen} e
2185 \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
2186 dello standard POSIX.1.} i loro prototipi sono:
2189 \funcdecl{FILE *fopen(const char *path, const char *mode)}
2190 Apre il file specificato da \param{path}.
2191 \funcdecl{FILE *fdopen(int fildes, const char *mode)}
2192 Associa uno \textit{stream} al file descriptor \param{fildes}.
2193 \funcdecl{FILE *freopen(const char *path, const char *mode, FILE *stream)}
2194 Apre il file specificato da \param{path} associandolo allo \textit{stream}
2195 specificato da \param{stream}, se questo è già aperto prima lo chiude.
2197 \bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
2198 \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
2199 ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
2201 Gli errori pertanto possono essere quelli di \func{malloc} per tutte
2202 e tre le funzioni, quelli \func{open} per \func{fopen}, quelli di
2203 \func{fcntl} per \func{fdopen} e quelli di \func{fopen},
2204 \func{fclose} e \func{fflush} per \func{freopen}.}
2207 Normalmente la funzione che si usa per aprire uno \textit{stream} è
2208 \func{fopen}, essa apre il file specificato nella modalità specificata da
2209 \param{mode}, che è una stringa che deve iniziare con almeno uno dei valori
2210 indicati in tab.~\ref{tab:file_fopen_mode} (sono possibili varie estensioni
2211 che vedremo in seguito).
2213 L'uso più comune di \func{freopen} è per redirigere uno dei tre file
2214 standard (vedi sez.~\ref{sec:file_std_stream}): il file \param{path} viene
2215 associato a \param{stream} e se questo è uno \textit{stream} già aperto viene
2216 preventivamente chiuso.
2218 Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
2219 descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
2220 \func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
2221 usare gli \textit{stream} con file come le fifo o i socket, che non possono
2222 essere aperti con le funzioni delle librerie standard del C.
2227 \begin{tabular}[c]{|l|p{8cm}|}
2229 \textbf{Valore} & \textbf{Significato}\\
2232 \texttt{r} & Il file viene aperto, l'accesso viene posto in sola
2233 lettura, lo \textit{stream} è posizionato all'inizio del
2235 \texttt{r+}& Il file viene aperto, l'accesso viene posto in lettura e
2236 scrittura, lo \textit{stream} è posizionato all'inizio del
2239 \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
2240 creato se non esiste), l'accesso viene posto in sola
2241 scrittura, lo stream\textit{} è posizionato all'inizio del
2243 \texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
2244 creato se non esiste), l'accesso viene posto in scrittura e
2245 lettura, lo \textit{stream} è posizionato all'inizio del
2248 \texttt{a} & Il file viene aperto (o creato se non esiste) in
2249 \itindex{append~mode} \textit{append mode}, l'accesso viene
2250 posto in sola scrittura.\\
2251 \texttt{a+}& Il file viene aperto (o creato se non esiste) in
2252 \itindex{append~mode} \textit{append mode}, l'accesso viene
2253 posto in lettura e scrittura.\\
2255 \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
2256 \texttt{x} & L'apertura fallisce se il file esiste già. \\
2259 \caption{Modalità di apertura di uno \textit{stream} dello standard ANSI C
2260 che sono sempre presenti in qualunque sistema POSIX.}
2261 \label{tab:file_fopen_mode}
2264 In realtà lo standard ANSI C prevede un totale di 15 possibili valori
2265 diversi per \param{mode}, ma in tab.~\ref{tab:file_fopen_mode} si sono
2266 riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
2267 il carattere \texttt{b} (come ultimo carattere o nel mezzo agli altri per
2268 le stringhe di due caratteri) che in altri sistemi operativi serve a
2269 distinguere i file binari dai file di testo; in un sistema POSIX questa
2270 distinzione non esiste e il valore viene accettato solo per
2271 compatibilità, ma non ha alcun effetto.
2273 Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
2274 indicate dopo aver specificato il \param{mode} con uno dei valori di
2275 tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
2276 evitare di sovrascrivere un file già esistente (è analoga all'uso
2277 dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
2278 esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
2281 Un'altra estensione serve a supportare la localizzazione, quando si
2282 aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
2283 valore \verb|STRING| è considerato il nome di una codifica dei caratteri
2284 e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
2285 opportune funzioni di conversione in lettura e scrittura.
2287 Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
2288 essere compatibili con quelli con cui il file descriptor è stato aperto.
2289 Inoltre i modi \cmd{w} e \cmd{w+} non troncano il file. La posizione nello
2290 \textit{stream} viene impostata a quella corrente nel file descriptor, e le
2291 variabili di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono
2292 cancellate. Il file non viene duplicato e verrà chiuso alla chiusura dello
2295 I nuovi file saranno creati secondo quanto visto in
2296 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
2298 \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
2299 \val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
2300 il processo (si veda sez.~\ref{sec:file_perm_management}).
2302 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
2303 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
2304 richiede che ci sia un'operazione di posizionamento fra un'operazione
2305 di output ed una di input o viceversa (eccetto il caso in cui l'input ha
2306 incontrato la fine del file), altrimenti una lettura può ritornare anche
2307 il risultato di scritture precedenti l'ultima effettuata.
2309 Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
2310 una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
2311 \func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
2312 voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
2313 usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
2314 un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
2315 sufficiente a garantire la sincronizzazione.
2317 Una volta aperto lo \textit{stream}, si può cambiare la modalità di
2318 bufferizzazione (si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non
2319 si è effettuato alcuna operazione di I/O sul file.
2321 Uno \textit{stream} viene chiuso con la funzione \funcd{fclose} il cui
2323 \begin{prototype}{stdio.h}{int fclose(FILE *stream)}
2324 Chiude lo \textit{stream} \param{stream}.
2326 \bodydesc{Restituisce 0 in caso di successo e \val{EOF} in caso di errore,
2327 nel qual caso imposta \var{errno} a \errval{EBADF} se il file descriptor
2328 indicato da \param{stream} non è valido, o uno dei valori specificati
2329 dalla sottostante funzione che è fallita (\func{close}, \func{write} o
2333 La funzione effettua lo scarico di tutti i dati presenti nei buffer di uscita
2334 e scarta tutti i dati in ingresso; se era stato allocato un buffer per lo
2335 \textit{stream} questo verrà rilasciato. La funzione effettua lo scarico solo
2336 per i dati presenti nei buffer in user space usati dalle \acr{glibc}; se si
2337 vuole essere sicuri che il kernel forzi la scrittura su disco occorrerà
2338 effettuare una \func{sync} (vedi sez.~\ref{sec:file_sync}).
2340 Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
2341 GNU implementata dalle \acr{glibc}, accessibile avendo definito
2342 \macro{\_GNU\_SOURCE}, il suo prototipo è:
2343 \begin{prototype}{stdio.h}{int fcloseall(void)}
2344 Chiude tutti gli \textit{stream}.
2346 \bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
2348 \noindent la funzione esegue lo scarico dei dati bufferizzati in uscita
2349 e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
2350 provvista solo per i casi di emergenza, quando si è verificato un errore
2351 ed il programma deve essere abortito, ma si vuole compiere qualche altra
2352 operazione dopo aver chiuso i file e prima di uscire (si ricordi quanto
2353 visto in sez.~\ref{sec:proc_conclusion}).
2356 \subsection{Lettura e scrittura su uno \textit{stream}}
2359 Una delle caratteristiche più utili dell'interfaccia degli \textit{stream} è
2360 la ricchezza delle funzioni disponibili per le operazioni di lettura e
2361 scrittura sui file. Sono infatti previste ben tre diverse modalità modalità di
2362 input/output non formattato:
2364 \item\textsl{binario} in cui legge/scrive un blocco di dati alla
2365 volta, vedi sez.~\ref{sec:file_binary_io}.
2366 \item\textsl{a caratteri} in cui si legge/scrive un carattere alla
2367 volta (con la bufferizzazione gestita automaticamente dalla libreria),
2368 vedi sez.~\ref{sec:file_char_io}.
2369 \item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
2370 dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
2372 ed inoltre la modalità di input/output formattato.
2374 A differenza dell'interfaccia dei file descriptor, con gli \textit{stream} il
2375 raggiungimento della fine del file è considerato un errore, e viene
2376 notificato come tale dai valori di uscita delle varie funzioni. Nella
2377 maggior parte dei casi questo avviene con la restituzione del valore
2378 intero (di tipo \ctyp{int}) \val{EOF}\footnote{la costante deve essere
2379 negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
2380 valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
2382 Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
2383 libreria che si appoggiano a delle \textit{system call}, esse non impostano
2384 direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
2385 \textit{system call} che ha riportato l'errore.
2387 Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
2388 il problema di come distinguerla da un errore effettivo; basarsi solo sul
2389 valore di ritorno della funzione e controllare il valore di \var{errno}
2390 infatti non basta, dato che quest'ultimo potrebbe essere stato impostato in
2391 una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del
2392 funzionamento di \var{errno}).
2394 Per questo motivo tutte le implementazioni delle librerie standard mantengono
2395 per ogni \textit{stream} almeno due flag all'interno dell'oggetto \type{FILE},
2396 il flag di \textit{end-of-file}, che segnala che si è raggiunta la fine del
2397 file in lettura, e quello di errore, che segnala la presenza di un qualche
2398 errore nelle operazioni di input/output; questi due flag possono essere
2399 riletti dalle funzioni \funcd{feof} e \funcd{ferror}, i cui prototipi sono:
2402 \funcdecl{int feof(FILE *stream)}
2403 Controlla il flag di end-of-file di \param{stream}.
2404 \funcdecl{int ferror(FILE *stream)}
2405 Controlla il flag di errore di \param{stream}.
2407 \bodydesc{Entrambe le funzioni ritornano un valore diverso da zero se
2408 i relativi flag sono impostati.}
2410 \noindent si tenga presente comunque che la lettura di questi flag segnala
2411 soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
2412 qualunque operazione sullo \textit{stream}, il controllo quindi deve essere
2413 effettuato ogni volta che si chiama una funzione di libreria.
2415 Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
2416 la funzione \funcd{clearerr}, il cui prototipo è:
2417 \begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
2418 Cancella i flag di errore ed \textit{end-of-file} di \param{stream}.
2420 \noindent in genere si usa questa funzione una volta che si sia identificata e
2421 corretta la causa di un errore per evitare di mantenere i flag attivi, così da
2422 poter rilevare una successiva ulteriore condizione di errore. Di questa
2423 funzione esiste una analoga \funcm{clearerr\_unlocked} che non esegue il
2424 blocco dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
2427 \subsection{Input/output binario}
2428 \label{sec:file_binary_io}
2430 La prima modalità di input/output non formattato ricalca quella della
2431 interfaccia dei file descriptor, e provvede semplicemente la scrittura e la
2432 lettura dei dati da un buffer verso un file e viceversa. In generale questa è
2433 la modalità che si usa quando si ha a che fare con dati non formattati. Le due
2434 funzioni che si usano per l'I/O binario sono \funcd{fread} ed \funcd{fwrite};
2435 i loro prototipi sono:
2439 \funcdecl{size\_t fread(void *ptr, size\_t size, size\_t nmemb, FILE
2442 \funcdecl{size\_t fwrite(const void *ptr, size\_t size, size\_t
2443 nmemb, FILE *stream)}
2445 Rispettivamente leggono e scrivono \param{nmemb} elementi di dimensione
2446 \param{size} dal buffer \param{ptr} al file \param{stream}.
2448 \bodydesc{Entrambe le funzioni ritornano il numero di elementi letti o
2449 scritti, in caso di errore o fine del file viene restituito un numero di
2450 elementi inferiore al richiesto.}
2453 In genere si usano queste funzioni quando si devono trasferire su file
2454 blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
2455 tipico è quello in cui si salva un vettore (o un certo numero dei suoi
2456 elementi) con una chiamata del tipo:
2457 \includecodesnip{listati/WriteVect.c}
2458 in questo caso devono essere specificate le dimensioni di ciascun
2459 elemento ed il numero di quelli che si vogliono scrivere. Un secondo
2460 caso è invece quello in cui si vuole trasferire su file una struttura;
2461 si avrà allora una chiamata tipo:
2462 \includecodesnip{listati/WriteStruct.c}
2463 in cui si specifica la dimensione dell'intera struttura ed un solo
2466 In realtà quello che conta nel trasferimento dei dati sono le dimensioni
2467 totali, che sono sempre pari al prodotto \code{size * nelem}; la sola
2468 differenza è che le funzioni non ritornano il numero di byte scritti,
2469 ma il numero di elementi.
2471 La funzione \func{fread} legge sempre un numero intero di elementi, se
2472 incontra la fine del file l'oggetto letto parzialmente viene scartato (lo
2473 stesso avviene in caso di errore). In questo caso la posizione dello
2474 \textit{stream} viene impostata alla fine del file (e non a quella
2475 corrispondente alla quantità di dati letti).
2477 In caso di errore (o fine del file per \func{fread}) entrambe le
2478 funzioni restituiscono il numero di oggetti effettivamente letti o
2479 scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
2480 avviene per i file descriptor, questo segnala una condizione di errore e
2481 occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
2484 Benché queste funzioni assicurino la massima efficienza per il
2485 salvataggio dei dati, i dati memorizzati attraverso di esse presentano
2486 lo svantaggio di dipendere strettamente dalla piattaforma di sviluppo
2487 usata ed in genere possono essere riletti senza problemi solo dallo
2488 stesso programma che li ha prodotti.
2490 Infatti diversi compilatori possono eseguire ottimizzazioni diverse delle
2491 strutture dati e alcuni compilatori (come il \cmd{gcc}) possono anche
2492 scegliere se ottimizzare l'occupazione di spazio, impacchettando più
2493 strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
2494 l'allineamento dei medesimi generando quindi output binari diversi. Inoltre
2495 altre incompatibilità si possono presentare quando entrano in gioco differenze
2496 di architettura hardware, come la dimensione del bus o la modalità di
2497 ordinamento dei bit o il formato delle variabili in floating point.
2499 Per questo motivo quando si usa l'input/output binario occorre sempre prendere
2500 le opportune precauzioni (in genere usare un formato di più alto livello che
2501 permetta di recuperare l'informazione completa), per assicurarsi che versioni
2502 diverse del programma siano in grado di rileggere i dati tenendo conto delle
2503 eventuali differenze.
2505 Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
2506 \funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
2507 implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
2508 applicazioni \itindex{thread} \textit{multi-thread} (si veda
2509 sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
2513 \funcdecl{size\_t fread\_unlocked(void *ptr, size\_t size, size\_t
2514 nmemb, FILE *stream)}
2516 \funcdecl{size\_t fwrite\_unlocked(const void *ptr, size\_t size,
2517 size\_t nmemb, FILE *stream)}
2519 \bodydesc{Le funzioni sono identiche alle analoghe \func{fread} e
2520 \func{fwrite} ma non acquisiscono il lock implicito sullo \textit{stream}.}
2522 \noindent entrambe le funzioni sono estensioni GNU previste solo dalle
2526 \subsection{Input/output a caratteri}
2527 \label{sec:file_char_io}
2529 La seconda modalità di input/output è quella a caratteri, in cui si
2530 trasferisce un carattere alla volta. Le funzioni per la lettura a
2531 caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, i
2532 rispettivi prototipi sono:
2536 \funcdecl{int getc(FILE *stream)} Legge un byte da \param{stream} e lo
2537 restituisce come intero. In genere è implementata come una macro.
2539 \funcdecl{int fgetc(FILE *stream)} Legge un byte da \param{stream} e lo
2540 restituisce come intero. È sempre una funzione.
2542 \funcdecl{int getchar(void)} Equivalente a \code{getc(stdin)}.
2544 \bodydesc{Tutte queste funzioni leggono un byte alla volta, che viene
2545 restituito come intero; in caso di errore o fine del file il valore
2546 di ritorno è \val{EOF}.}
2549 A parte \func{getchar}, che si usa in genere per leggere un carattere da
2550 tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
2551 differenza è che \func{getc} è ottimizzata al massimo e normalmente
2552 viene implementata con una macro, per cui occorre stare attenti a cosa
2553 le si passa come argomento, infatti \param{stream} può essere valutato
2554 più volte nell'esecuzione, e non viene passato in copia con il
2555 meccanismo visto in sez.~\ref{sec:proc_var_passing}; per questo motivo se
2556 si passa un'espressione si possono avere effetti indesiderati.
2558 Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
2559 la sua esecuzione normalmente è più lenta per via dell'overhead della
2560 chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
2561 come argomento ad un altra funzione (e non si hanno i problemi accennati in
2562 precedenza nel tipo di argomento).
2564 Le tre funzioni restituiscono tutte un \ctyp{unsigned char} convertito
2565 ad \ctyp{int} (si usa \ctyp{unsigned char} in modo da evitare
2566 l'espansione del segno). In questo modo il valore di ritorno è sempre
2567 positivo, tranne in caso di errore o fine del file.
2569 Nelle estensioni GNU che provvedono la localizzazione sono definite tre
2570 funzioni equivalenti alle precedenti, \funcd{getwc}, \funcd{fgetwc} e
2571 \funcd{getwchar}, che invece di un carattere di un byte restituiscono un
2572 carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
2578 \funcdecl{wint\_t getwc(FILE *stream)} Legge un carattere esteso da
2579 \param{stream}. In genere è implementata come una macro.
2581 \funcdecl{wint\_t fgetwc(FILE *stream)} Legge un carattere esteso da
2582 \param{stream}. È una sempre una funzione.
2584 \funcdecl{wint\_t getwchar(void)} Equivalente a \code{getwc(stdin)}.
2586 \bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
2587 caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
2590 Per scrivere un carattere si possono usare tre funzioni, analoghe alle
2591 precedenti usate per leggere: \funcd{putc}, \funcd{fputc} e \funcd{putchar}; i
2592 loro prototipi sono:
2596 \funcdecl{int putc(int c, FILE *stream)} Scrive il carattere \param{c}
2597 su \param{stream}. In genere è implementata come una macro.
2599 \funcdecl{int fputc(int c, FILE *stream)} Scrive il carattere \param{c} su
2600 \param{stream}. È una sempre una funzione.
2602 \funcdecl{int putchar(int c)} Equivalente a \code{putc(stdout)}.
2604 \bodydesc{Le funzioni scrivono sempre un carattere alla volta, il cui
2605 valore viene restituito in caso di successo; in caso di errore o
2606 fine del file il valore di ritorno è \val{EOF}.}
2609 Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
2610 come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
2611 un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
2612 caso di errore o fine del file il valore di ritorno è \val{EOF}.
2614 Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
2615 provvedono come estensione, per ciascuna delle funzioni precedenti,
2616 un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
2617 \code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
2618 il lock implicito dello \textit{stream}.
2620 Per compatibilità con SVID sono inoltre provviste anche due funzioni,
2621 \funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
2622 (cioè due byte in una volta); i loro prototipi sono:
2626 \funcdecl{int getw(FILE *stream)} Legge una parola da \param{stream}.
2627 \funcdecl{int putw(int w, FILE *stream)} Scrive la parola \param{w} su
2630 \bodydesc{Le funzioni restituiscono la parola \param{w}, o \val{EOF}
2631 in caso di errore o di fine del file.}
2634 Le funzioni leggono e scrivono una \textit{word} di due byte, usando comunque
2635 una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
2636 di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
2637 valore -1 da una condizione di errore che restituisce \val{EOF}.
2639 Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
2640 \textit{parsing} in cui si analizza il testo; in questo contesto diventa utile
2641 poter analizzare il carattere successivo da uno \textit{stream} senza estrarlo
2642 effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
2643 programma possa regolarsi avendo dato una \textsl{sbirciatina} a quello che
2646 Nel nostro caso questo tipo di comportamento può essere realizzato prima
2647 leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
2648 disponibile per una lettura successiva; la funzione che inverte la
2649 lettura si chiama \funcd{ungetc} ed il suo prototipo è:
2650 \begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
2651 Rimanda indietro il carattere \param{c}, con un cast a \ctyp{unsigned
2652 char}, sullo \textit{stream} \param{stream}.
2654 \bodydesc{La funzione ritorna \param{c} in caso di successo e
2655 \val{EOF} in caso di errore.}
2657 \noindent benché lo standard ANSI C preveda che l'operazione possa
2658 essere ripetuta per un numero arbitrario di caratteri, alle
2659 implementazioni è richiesto di garantire solo un livello; questo è
2660 quello che fa la \acr{glibc}, che richiede che avvenga un'altra
2661 operazione fra due \func{ungetc} successive.
2663 Non è necessario che il carattere che si manda indietro sia l'ultimo che
2664 si è letto, e non è necessario neanche avere letto nessun carattere
2665 prima di usare \func{ungetc}, ma di norma la funzione è intesa per
2666 essere usata per rimandare indietro l'ultimo carattere letto.
2668 Nel caso \param{c} sia un \val{EOF} la funzione non fa nulla, e
2669 restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
2670 con il risultato di una lettura alla fine del file.
2672 Se si è alla fine del file si può comunque rimandare indietro un
2673 carattere, il flag di end-of-file verrà automaticamente cancellato
2674 perché c'è un nuovo carattere disponibile che potrà essere riletto
2677 Infine si tenga presente che \func{ungetc} non altera il contenuto del
2678 file, ma opera esclusivamente sul buffer interno. Se si esegue una
2679 qualunque delle operazioni di riposizionamento (vedi
2680 sez.~\ref{sec:file_fseek}) i caratteri rimandati indietro vengono
2684 \subsection{Input/output di linea}
2685 \label{sec:file_line_io}
2687 La terza ed ultima modalità di input/output non formattato è quella di linea,
2688 in cui si legge o si scrive una riga alla volta; questa è una modalità molto
2689 usata per l'I/O da terminale, ma è anche quella che presenta le
2690 caratteristiche più controverse.
2692 Le funzioni previste dallo standard ANSI C per leggere una linea sono
2693 sostanzialmente due, \funcd{gets} e \funcd{fgets}, i cui rispettivi
2698 \funcdecl{char *gets(char *string)} Scrive su \param{string} una
2699 linea letta da \var{stdin}.
2701 \funcdecl{char *fgets(char *string, int size, FILE *stream)}
2702 Scrive su \param{string} la linea letta da \param{stream} per un
2703 massimo di \param{size} byte.
2705 \bodydesc{Le funzioni restituiscono l'indirizzo \param{string} in caso
2706 di successo o \val{NULL} in caso di errore.}
2709 Entrambe le funzioni effettuano la lettura (dal file specificato \func{fgets},
2710 dallo standard input \func{gets}) di una linea di caratteri (terminata dal
2711 carattere \textit{newline}, \verb|'\n'|, quello mappato sul tasto di ritorno a
2712 capo della tastiera), ma \func{gets} sostituisce \verb|'\n'| con uno zero,
2713 mentre \func{fgets} aggiunge uno zero dopo il \textit{newline}, che resta
2714 dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
2715 viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
2716 L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
2717 funzione infatti non controlla il numero di byte letti, per cui nel caso la
2718 stringa letta superi le dimensioni del buffer, si avrà un
2719 \itindex{buffer~overflow} \textit{buffer overflow}, con sovrascrittura della
2720 memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
2721 in dettaglio e con molta efficacia nell'ormai famoso articolo di Aleph1
2724 Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
2725 autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
2726 una stringa sufficientemente lunga ed opportunamente forgiata per
2727 sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
2728 (supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
2729 far ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere
2730 uno \textit{shell code} cioè una sezione di programma che lancia una shell).
2732 La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
2733 prende in input la dimensione del buffer \param{size}, che non verrà mai
2734 ecceduta in lettura. La funzione legge fino ad un massimo di \param{size}
2735 caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
2736 comporta che la stringa possa essere al massimo di \code{size-1} caratteri. Se
2737 la linea eccede la dimensione del buffer verranno letti solo \code{size-1}
2738 caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
2739 finale; sarà possibile leggere i rimanenti caratteri in una chiamata
2742 Per la scrittura di una linea lo standard ANSI C prevede altre due
2743 funzioni, \funcd{fputs} e \funcd{puts}, analoghe a quelle di lettura, i
2744 rispettivi prototipi sono:
2748 \funcdecl{int puts(const char *string)} Scrive su \var{stdout} la
2749 linea \param{string}.
2751 \funcdecl{int fputs(const char *string, FILE *stream)} Scrive su
2752 \param{stream} la linea \param{string}.
2754 \bodydesc{Le funzioni restituiscono un valore non negativo in caso di
2755 successo o \val{EOF} in caso di errore.}
2758 Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
2759 problemi di \func{gets} ed è in genere la forma più immediata per scrivere
2760 messaggi sullo standard output; la funzione prende una stringa terminata da
2761 uno zero ed aggiunge automaticamente il ritorno a capo. La differenza con
2762 \func{fputs} (a parte la possibilità di specificare un file diverso da
2763 \var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
2764 previsto esplicitamente.
2766 Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
2767 linea esistono delle estensioni per leggere e scrivere linee di caratteri
2768 estesi, le funzioni in questione sono \funcd{fgetws} e \funcd{fputws} ed i
2769 loro prototipi sono:
2772 \funcdecl{wchar\_t *fgetws(wchar\_t *ws, int n, FILE *stream)}
2773 Legge un massimo di \param{n} caratteri estesi dal file
2774 \param{stream} al buffer \param{ws}.
2776 \funcdecl{int fputws(const wchar\_t *ws, FILE *stream)} Scrive la
2777 linea \param{ws} di caratteri estesi sul file \param{stream}.
2779 \bodydesc{Le funzioni ritornano rispettivamente \param{ws} o un numero
2780 non negativo in caso di successo e \val{NULL} o \val{EOF} in
2781 caso di errore o fine del file.}
2784 Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
2785 \func{fputs}, a parte il fatto che tutto (numero di caratteri massimo,
2786 terminatore della stringa, newline) è espresso in termini di caratteri estesi
2787 anziché di normali caratteri ASCII.
2789 Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
2790 \acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
2791 illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
2792 esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
2793 implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
2794 per le altre forma di I/O, dette funzioni hanno lo stesso nome della loro
2795 analoga normale, con l'aggiunta dell'estensione \code{\_unlocked}.
2797 Come abbiamo visto, le funzioni di lettura per l'input/output di linea
2798 previste dallo standard ANSI C presentano svariati inconvenienti. Benché
2799 \func{fgets} non abbia i gravissimi problemi di \func{gets}, può
2800 comunque dare risultati ambigui se l'input contiene degli zeri; questi
2801 infatti saranno scritti sul buffer di uscita e la stringa in output
2802 apparirà come più corta dei byte effettivamente letti. Questa è una
2803 condizione che è sempre possibile controllare (deve essere presente un
2804 newline prima della effettiva conclusione della stringa presente nel
2805 buffer), ma a costo di una complicazione ulteriore della logica del
2806 programma. Lo stesso dicasi quando si deve gestire il caso di stringa
2807 che eccede le dimensioni del buffer.
2809 Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
2810 funzioni per la gestione dell'input/output di linea, il cui uso permette di
2811 risolvere questi problemi. L'uso di queste funzioni deve essere attivato
2812 definendo la macro \macro{\_GNU\_SOURCE} prima di includere
2813 \headfile{stdio.h}. La prima delle due, \funcd{getline}, serve per leggere una
2814 linea terminata da un newline, esattamente allo stesso modo di \func{fgets},
2816 \begin{prototype}{stdio.h}
2817 {ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
2818 dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
2819 riallocandolo se necessario (l'indirizzo del buffer e la sua dimensione
2820 vengono sempre riscritte).
2822 \bodydesc{La funzione ritorna il numero di caratteri letti in caso di
2823 successo e -1 in caso di errore o di raggiungimento della fine del
2827 La funzione permette di eseguire una lettura senza doversi preoccupare della
2828 eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
2829 argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
2830 linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
2831 \func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
2832 locale); come secondo argomento la funzione vuole l'indirizzo della variabile
2833 contenente le dimensioni del buffer suddetto.
2835 Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
2836 subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
2837 dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti
2838 come per entrambi gli argomenti si siano usati dei
2839 \itindex{value~result~argument} \textit{value result argument}, passando dei
2840 puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
2841 sez.~\ref{sec:proc_var_passing}).
2843 Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
2844 \var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
2845 necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
2846 puntatore all'inizio del testo della linea letta. Un esempio di codice può
2848 \includecodesnip{listati/getline.c}
2849 e per evitare \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
2850 liberare \var{ptr} con una \func{free}.
2852 Il valore di ritorno della funzione indica il numero di caratteri letti
2853 dallo \textit{stream} (quindi compreso il newline, ma non lo zero di
2854 terminazione); questo permette anche di distinguere eventuali zeri letti
2855 dallo \textit{stream} da quello inserito dalla funzione per terminare la linea.
2856 Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
2857 un errore la funzione restituisce -1.
2859 La seconda estensione GNU è una generalizzazione di \func{getline} per
2860 poter usare come separatore un carattere qualsiasi, la funzione si
2861 chiama \funcd{getdelim} ed il suo prototipo è:
2862 \begin{prototype}{stdio.h}
2863 {ssize\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)}
2864 Identica a \func{getline} solo che usa \param{delim} al posto del
2865 carattere di newline come separatore di linea.
2868 Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
2869 può essere implementata da questa passando \verb|'\n'| come valore di
2873 \subsection{L'input/output formattato}
2874 \label{sec:file_formatted_io}
2876 L'ultima modalità di input/output è quella formattata, che è una delle
2877 caratteristiche più utilizzate delle librerie standard del C; in genere questa
2878 è la modalità in cui si esegue normalmente l'output su terminale poiché
2879 permette di stampare in maniera facile e veloce dati, tabelle e messaggi.
2881 L'output formattato viene eseguito con una delle 13 funzioni della famiglia
2882 \func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
2883 \funcd{sprintf}, i cui prototipi sono:
2886 \funcdecl{int printf(const char *format, ...)} Stampa su \file{stdout}
2887 gli argomenti, secondo il formato specificato da \param{format}.
2889 \funcdecl{int fprintf(FILE *stream, const char *format, ...)} Stampa
2890 su \param{stream} gli argomenti, secondo il formato specificato da
2893 \funcdecl{int sprintf(char *str, const char *format, ...)} Stampa
2894 sulla stringa \param{str} gli argomenti, secondo il formato
2895 specificato da \param{format}.
2897 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
2899 \noindent le prime due servono per stampare su file (lo standard output o
2900 quello specificato) la terza permette di stampare su una stringa, in genere
2901 l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
2902 sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
2903 dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
2904 possibili \itindex{buffer~overflow} \textit{buffer overflow}; per questo
2905 motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
2907 \begin{prototype}{stdio.h}
2908 {snprintf(char *str, size\_t size, const char *format, ...)}
2909 Identica a \func{sprintf}, ma non scrive su \param{str} più di
2910 \param{size} caratteri.
2913 La parte più complessa delle funzioni di scrittura formattata è il formato
2914 della stringa \param{format} che indica le conversioni da fare, e da cui
2915 deriva anche il numero degli argomenti che dovranno essere passati a seguire
2916 (si noti come tutte queste funzioni siano \index{funzioni!variadic}
2917 \textit{variadic}, prendendo un numero di argomenti variabile che dipende
2918 appunto da quello che si è specificato in \param{format}).
2923 \begin{tabular}[c]{|l|l|p{10cm}|}
2925 \textbf{Valore} & \textbf{Tipo} & \textbf{Significato} \\
2928 \cmd{\%d} &\ctyp{int} & Stampa un numero intero in formato decimale
2930 \cmd{\%i} &\ctyp{int} & Identico a \cmd{\%i} in output.\\
2931 \cmd{\%o} &\ctyp{unsigned int}& Stampa un numero intero come ottale.\\
2932 \cmd{\%u} &\ctyp{unsigned int}& Stampa un numero intero in formato
2933 decimale senza segno.\\
2935 \cmd{\%X} &\ctyp{unsigned int}& Stampano un intero in formato esadecimale,
2936 rispettivamente con lettere minuscole e
2938 \cmd{\%f} &\ctyp{double} & Stampa un numero in virgola mobile con la
2939 notazione a virgola fissa.\\
2941 \cmd{\%E} &\ctyp{double} & Stampano un numero in virgola mobile con la
2942 notazione esponenziale, rispettivamente con
2943 lettere minuscole e maiuscole.\\
2945 \cmd{\%G} &\ctyp{double} & Stampano un numero in virgola mobile con la
2946 notazione più appropriate delle due precedenti,
2947 rispettivamente con lettere minuscole e
2950 \cmd{\%A} &\ctyp{double} & Stampano un numero in virgola mobile in
2951 notazione esadecimale frazionaria.\\
2952 \cmd{\%c} &\ctyp{int} & Stampa un carattere singolo.\\
2953 \cmd{\%s} &\ctyp{char *} & Stampa una stringa.\\
2954 \cmd{\%p} &\ctyp{void *} & Stampa il valore di un puntatore.\\
2955 \cmd{\%n} &\ctyp{\&int} & Prende il numero di caratteri stampati finora.\\
2956 \cmd{\%\%}& & Stampa un \%.\\
2959 \caption{Valori possibili per gli specificatori di conversione in una
2960 stringa di formato di \func{printf}.}
2961 \label{tab:file_format_spec}
2964 La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
2965 vengono passati invariati all'output, e da direttive di conversione, in cui
2966 devono essere sempre presenti il carattere \texttt{\%}, che introduce la
2967 direttiva, ed uno degli specificatori di conversione (riportati in
2968 tab.~\ref{tab:file_format_spec}) che la conclude.
2973 \begin{tabular}[c]{|l|p{10cm}|}
2975 \textbf{Valore} & \textbf{Significato}\\
2978 \val{\#} & Chiede la conversione in forma alternativa. \\
2979 \val{0} & La conversione è riempita con zeri alla sinistra del valore.\\
2980 \val{-} & La conversione viene allineata a sinistra sul bordo del campo.\\
2981 \val{' '}& Mette uno spazio prima di un numero con segno di valore
2983 \val{+} & Mette sempre il segno ($+$ o $-$) prima di un numero.\\
2986 \caption{I valori dei flag per il formato di \func{printf}}
2987 \label{tab:file_format_flag}
2990 Il formato di una direttiva di conversione prevede una serie di possibili
2991 elementi opzionali oltre al \cmd{\%} e allo specificatore di conversione. In
2992 generale essa è sempre del tipo:
2995 % [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
2998 in cui tutti i valori tranne il \val{\%} e lo specificatore di conversione
2999 sono opzionali (e per questo sono indicati fra parentesi quadre); si possono
3000 usare più elementi opzionali, nel qual caso devono essere specificati in
3003 \item uno specificatore del parametro da usare (terminato da un \val{\$}),
3004 \item uno o più flag (i cui valori possibili sono riassunti in
3005 tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
3007 \item uno specificatore di larghezza (un numero decimale), eventualmente
3008 seguito (per i numeri in virgola mobile) da un specificatore di precisione
3009 (un altro numero decimale),
3010 \item uno specificatore del tipo di dato, che ne indica la dimensione (i cui
3011 valori possibili sono riassunti in tab.~\ref{tab:file_format_type}).
3015 Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di
3016 manuale di \func{printf} e nella documentazione delle \acr{glibc}.
3021 \begin{tabular}[c]{|l|p{10cm}|}
3023 \textbf{Valore} & \textbf{Significato} \\
3026 \cmd{hh} & Una conversione intera corrisponde a un \ctyp{char} con o senza
3027 segno, o il puntatore per il numero dei parametri \cmd{n} è di
3029 \cmd{h} & Una conversione intera corrisponde a uno \ctyp{short} con o
3030 senza segno, o il puntatore per il numero dei parametri \cmd{n}
3031 è di tipo \ctyp{short}.\\
3032 \cmd{l} & Una conversione intera corrisponde a un \ctyp{long} con o
3033 senza segno, o il puntatore per il numero dei parametri \cmd{n}
3034 è di tipo \ctyp{long}, o il carattere o la stringa seguenti
3035 sono in formato esteso.\\
3036 \cmd{ll} & Una conversione intera corrisponde a un \ctyp{long long} con o
3037 senza segno, o il puntatore per il numero dei parametri \cmd{n}
3038 è di tipo \ctyp{long long}.\\
3039 \cmd{L} & Una conversione in virgola mobile corrisponde a un
3041 \cmd{q} & Sinonimo di \cmd{ll}.\\
3042 \cmd{j} & Una conversione intera corrisponde a un \type{intmax\_t} o
3043 \type{uintmax\_t}.\\
3044 \cmd{z} & Una conversione intera corrisponde a un \type{size\_t} o
3046 \cmd{t} & Una conversione intera corrisponde a un \type{ptrdiff\_t}.\\
3049 \caption{Il modificatore di tipo di dato per il formato di \func{printf}}
3050 \label{tab:file_format_type}
3053 Una versione alternativa delle funzioni di output formattato, che permettono
3054 di usare il puntatore ad una lista variabile \index{funzioni!variadic} di
3055 argomenti (vedi sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf},
3056 \funcd{vfprintf} e \funcd{vsprintf}, i cui prototipi sono:
3060 \funcdecl{int vprintf(const char *format, va\_list ap)} Stampa su
3061 \var{stdout} gli argomenti della lista \param{ap}, secondo il formato
3062 specificato da \param{format}.
3064 \funcdecl{int vfprintf(FILE *stream, const char *format, va\_list ap)}
3065 Stampa su \param{stream} gli argomenti della lista \param{ap}, secondo il
3066 formato specificato da \param{format}.
3068 \funcdecl{int vsprintf(char *str, const char *format, va\_list ap)} Stampa
3069 sulla stringa \param{str} gli argomenti della lista \param{ap}, secondo il
3070 formato specificato da \param{format}.
3072 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
3074 \noindent con queste funzioni diventa possibile selezionare gli argomenti che
3075 si vogliono passare ad una funzione di stampa, passando direttamente la lista
3076 tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
3077 variabile\index{funzioni!variadic} degli argomenti dovrà essere opportunamente
3078 trattata (l'argomento è esaminato in sez.~\ref{sec:proc_variadic}), e dopo
3079 l'esecuzione della funzione l'argomento
3080 \param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
3081 \code{va\_end(ap)} ma in Linux questo non è necessario).
3083 Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
3084 \funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
3085 scritti sulla stringa di destinazione:
3086 \begin{prototype}{stdio.h}
3087 {vsnprintf(char *str, size\_t size, const char *format, va\_list ap)}
3088 Identica a \func{vsprintf}, ma non scrive su \param{str} più di
3089 \param{size} caratteri.
3091 \noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
3095 Per eliminare alla radice questi problemi, le \acr{glibc} supportano una
3096 specifica estensione GNU che alloca dinamicamente tutto lo spazio necessario;
3097 l'estensione si attiva al solito definendo \macro{\_GNU\_SOURCE}, le due
3098 funzioni sono \funcd{asprintf} e \funcd{vasprintf}, ed i rispettivi prototipi
3103 \funcdecl{int asprintf(char **strptr, const char *format, ...)} Stampa gli
3104 argomenti specificati secondo il formato specificato da \param{format} su
3105 una stringa allocata automaticamente all'indirizzo \param{*strptr}.
3107 \funcdecl{int vasprintf(char **strptr, const char *format, va\_list ap)}
3108 Stampa gli argomenti della lista \param{ap} secondo il formato specificato
3109 da \param{format} su una stringa allocata automaticamente all'indirizzo
3112 \bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
3115 Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
3116 l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
3117 restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
3118 proposito dei \itindex{value~result~argument} \textit{value result argument})
3119 l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
3120 inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
3121 la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
3124 % TODO verificare se mettere prototipi di \func{dprintf} e \func{vdprintf}
3126 Infine una ulteriore estensione GNU definisce le due funzioni \funcm{dprintf} e
3127 \funcm{vdprintf}, che prendono un file descriptor al posto dello
3128 \textit{stream}. Altre estensioni permettono di scrivere con caratteri
3129 estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
3130 funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
3131 dettaglio nella documentazione delle \acr{glibc}.
3133 In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
3134 l'output formattato, l'input formattato viene eseguito con le funzioni della
3135 famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
3136 \funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono:
3138 \headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
3139 scansione di \file{stdin} cercando una corrispondenza di quanto letto con il
3140 formato dei dati specificato da \param{format}, ed effettua le relative
3141 conversione memorizzando il risultato negli argomenti seguenti.
3143 \funcdecl{int fscanf(FILE *stream, const char *format, ...)} Analoga alla
3144 precedente, ma effettua la scansione su \param{stream}.
3146 \funcdecl{int sscanf(char *str, const char *format, ...)} Analoga alle
3147 precedenti, ma effettua la scansione dalla stringa \param{str}.
3149 \bodydesc{Le funzioni ritornano il numero di elementi assegnati. Questi
3150 possono essere in numero inferiore a quelli specificati, ed anche zero.
3151 Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
3152 di errore o fine del file viene invece restituito \val{EOF}.}
3154 \noindent e come per le analoghe funzioni di scrittura esistono le relative
3155 \funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un puntatore ad
3156 una lista di argomenti.
3158 Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
3159 puntatori alle variabili che dovranno contenere le conversioni; questo è un
3160 primo elemento di disagio in quanto è molto facile dimenticarsi di questa
3163 Le funzioni leggono i caratteri dallo \textit{stream} (o dalla stringa) di
3164 input ed eseguono un confronto con quanto indicato in \param{format}, la
3165 sintassi di questo argomento è simile a quella usata per l'analogo di
3166 \func{printf}, ma ci sono varie differenze. Le funzioni di input infatti sono
3167 più orientate verso la lettura di testo libero che verso un input formattato
3168 in campi fissi. Uno spazio in \param{format} corrisponde con un numero
3169 qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
3170 virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
3171 esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
3172 si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
3175 Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
3176 eventuali caratteri diversi indicati dalla stringa di formato) effettuando le
3177 conversioni richieste; in caso la corrispondenza fallisca (o la funzione non
3178 sia in grado di effettuare una delle conversioni richieste) la scansione viene
3179 interrotta immediatamente e la funzione ritorna lasciando posizionato lo
3180 \textit{stream} al primo carattere che non corrisponde.
3182 Data la notevole complessità di uso di queste funzioni, che richiedono molta
3183 cura nella definizione delle corrette stringhe di formato e sono facilmente
3184 soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
3185 recuperare in caso di fallimento nelle corrispondenze, l'input formattato non
3186 è molto usato. In genere infatti quando si ha a che fare con un input
3187 relativamente semplice si preferisce usare l'input di linea ed effettuare
3188 scansione e conversione di quanto serve direttamente con una delle funzioni di
3189 conversione delle stringhe; se invece il formato è più complesso diventa più
3190 facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
3191 \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
3192 analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
3193 \cite{flex}.} per generare un analizzatore lessicale o il
3194 \cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
3195 parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo
3196 manuale \cite{bison}.} per generare un parser.
3199 \subsection{Posizionamento su uno \textit{stream}}
3200 \label{sec:file_fseek}
3202 Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
3203 all'interno di un file per effettuare operazioni di lettura o scrittura in un
3204 punto prestabilito; sempre che l'operazione di riposizionamento sia supportata
3205 dal file sottostante lo \textit{stream}, quando cioè si ha a che fare con
3206 quello che viene detto un file ad \textsl{accesso casuale}.\footnote{dato che
3207 in un sistema Unix esistono vari tipi di file, come le fifo ed i
3208 \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
3211 In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
3212 espressa da un intero positivo, rappresentato dal tipo \type{off\_t}, il
3213 problema è che alcune delle funzioni usate per il riposizionamento sugli
3214 \textit{stream} originano dalle prime versioni di Unix, in cui questo tipo non
3215 era ancora stato definito, e che in altri sistemi non è detto che la posizione
3216 su un file venga sempre rappresentata con il numero di caratteri dall'inizio
3217 (ad esempio in VMS può essere rappresentata come numero di record, più
3218 l'offset rispetto al record corrente).
3220 Tutto questo comporta la presenza di diverse funzioni che eseguono
3221 sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
3222 funzioni tradizionali usate per il riposizionamento della posizione in uno
3223 \textit{stream} sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
3227 \funcdecl{int fseek(FILE *stream, long offset, int whence)} Sposta la
3228 posizione nello \textit{stream} secondo quanto specificato
3229 tramite \param{offset} e \param{whence}.
3231 \funcdecl{void rewind(FILE *stream)} Riporta la posizione nello
3232 \textit{stream} all'inizio del file.
3235 L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
3236 descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
3237 particolare \param{whence} assume gli stessi valori già visti in
3238 sez.~\ref{sec:file_lseek}. La funzione restituisce 0 in caso di successo e -1
3239 in caso di errore. La funzione \func{rewind} riporta semplicemente la
3240 posizione corrente all'inizio dello \textit{stream}, ma non esattamente
3241 equivalente ad una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono
3242 cancellati anche i flag di errore e fine del file.
3244 Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
3246 \begin{prototype}{stdio.h}{long ftell(FILE *stream)}
3247 Legge la posizione attuale nello \textit{stream} \param{stream}.
3249 \bodydesc{La funzione restituisce la posizione corrente, o -1 in caso
3250 di fallimento, che può esser dovuto sia al fatto che il file non
3251 supporta il riposizionamento che al fatto che la posizione non può
3252 essere espressa con un \ctyp{long int}}
3254 \noindent la funzione restituisce la posizione come numero di byte
3255 dall'inizio dello \textit{stream}.
3257 Queste funzioni esprimono tutte la posizione nel file come un \ctyp{long int}.
3258 Dato che (ad esempio quando si usa un filesystem indicizzato a 64 bit) questo
3259 può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
3260 \funcd{fgetpos} e \funcd{fsetpos}, che invece usano il nuovo tipo
3261 \type{fpos\_t}, ed i cui prototipi sono:
3265 \funcdecl{int fsetpos(FILE *stream, fpos\_t *pos)} Imposta la posizione
3266 corrente nello \textit{stream} \param{stream} al valore specificato
3269 \funcdecl{int fgetpos(FILE *stream, fpos\_t *pos)} Legge la posizione
3270 corrente nello \textit{stream} \param{stream} e la scrive in \param{pos}.
3272 \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
3276 In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni
3277 \func{fseeko} e \func{ftello}, che sono assolutamente identiche alle
3278 precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
3279 \type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
3280 gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
3281 posizione sul file viene espressa con un valore a 64 bit come accade nei
3282 sistemi più moderni.
3284 % TODO: mettere prototipi espliciti fseeko e ftello o menzione?
3287 \section{Funzioni avanzate}
3288 \label{sec:file_stream_adv_func}
3290 In questa sezione esamineremo alcune funzioni avanzate che permettono di
3291 eseguire operazioni particolari sugli \textit{stream}, come leggerne gli
3292 attributi, controllarne le modalità di bufferizzazione, gestire direttamente i
3293 lock impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
3296 \subsection{Le funzioni di controllo}
3297 \label{sec:file_stream_cntrl}
3299 Al contrario di quanto avviene con i file descriptor, le librerie standard del
3300 C non prevedono nessuna funzione come la \func{fcntl} per il controllo degli
3301 attributi dei file. Però, dato che ogni \textit{stream} si appoggia ad un file
3302 descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
3303 il prototipo della funzione è:
3304 \begin{prototype}{stdio.h}{int fileno(FILE *stream)}
3305 Legge il file descriptor sottostante lo \textit{stream} \param{stream}.
3307 \bodydesc{Restituisce il numero del file descriptor in caso di successo, e
3308 -1 qualora \param{stream} non sia valido, nel qual caso imposta
3309 \var{errno} a \errval{EBADF}.}
3311 \noindent ed in questo modo diventa possibile usare direttamente \func{fcntl}.
3313 Questo permette di accedere agli attributi del file descriptor sottostante lo
3314 \textit{stream}, ma non ci dà nessuna informazione riguardo alle proprietà
3315 dello \textit{stream} medesimo. Le \acr{glibc} però supportano alcune
3316 estensioni derivate da Solaris, che permettono di ottenere informazioni utili.
3318 Ad esempio in certi casi può essere necessario sapere se un certo
3319 \textit{stream} è accessibile in lettura o scrittura. In genere questa
3320 informazione non è disponibile, e si deve ricordare come il file è stato
3321 aperto. La cosa può essere complessa se le operazioni vengono effettuate in
3322 una subroutine, che a questo punto necessiterà di informazioni aggiuntive
3323 rispetto al semplice puntatore allo \textit{stream}; questo può essere evitato
3324 con le due funzioni \funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui
3327 \headdecl{stdio\_ext.h}
3328 \funcdecl{int \_\_freadable(FILE *stream)}
3329 Restituisce un valore diverso da zero se \param{stream} consente la lettura.
3331 \funcdecl{int \_\_fwritable(FILE *stream)}
3332 Restituisce un valore diverso da zero se \param{stream} consente la
3335 \noindent che permettono di ottenere questa informazione.
3337 La conoscenza dell'ultima operazione effettuata su uno \textit{stream} aperto
3338 è utile in quanto permette di trarre conclusioni sullo stato del buffer e del
3339 suo contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
3340 servono a tale scopo, il loro prototipo è:
3342 \headdecl{stdio\_ext.h}
3343 \funcdecl{int \_\_freading(FILE *stream)}
3344 Restituisce un valore diverso da zero se \param{stream} è aperto in sola
3345 lettura o se l'ultima operazione è stata di lettura.
3347 \funcdecl{int \_\_fwriting(FILE *stream)}
3348 Restituisce un valore diverso da zero se \param{stream} è aperto in sola
3349 scrittura o se l'ultima operazione è stata di scrittura.
3352 Le due funzioni permettono di determinare di che tipo è stata l'ultima
3353 operazione eseguita su uno \textit{stream} aperto in lettura/scrittura;
3354 ovviamente se uno \textit{stream} è aperto in sola lettura (o sola scrittura)
3355 la modalità dell'ultima operazione è sempre determinata; l'unica ambiguità è
3356 quando non sono state ancora eseguite operazioni, in questo caso le funzioni
3357 rispondono come se una operazione ci fosse comunque stata.
3360 \subsection{Il controllo della bufferizzazione}
3361 \label{sec:file_buffering_ctrl}
3363 Come accennato in sez.~\ref{sec:file_buffering} le librerie definiscono una
3364 serie di funzioni che permettono di controllare il comportamento degli
3365 \textit{stream}; se non si è specificato nulla, la modalità di buffering viene
3366 decisa autonomamente sulla base del tipo di file sottostante, ed i buffer
3367 vengono allocati automaticamente.
3369 Però una volta che si sia aperto lo \textit{stream} (ma prima di aver compiuto
3370 operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
3371 funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
3373 \begin{prototype}{stdio.h}{int setvbuf(FILE *stream, char *buf, int mode,
3376 Imposta la bufferizzazione dello \textit{stream} \param{stream} nella
3377 modalità indicata da \param{mode}, usando \param{buf} come buffer di
3381 \bodydesc{Restituisce zero in caso di successo, ed un valore qualunque in
3382 caso di errore, nel qual caso \var{errno} viene impostata opportunamente.}
3385 La funzione permette di controllare tutti gli aspetti della bufferizzazione;
3386 l'utente può specificare un buffer da usare al posto di quello allocato dal
3387 sistema passandone alla funzione l'indirizzo in \param{buf} e la dimensione in
3390 Ovviamente se si usa un buffer specificato dall'utente questo deve essere
3391 stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
3392 \textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
3393 dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
3394 funzione, può anche essere usata una \index{variabili!automatiche} variabile
3395 automatica. In \headfile{stdio.h} è definita la macro \const{BUFSIZ}, che
3396 indica le dimensioni generiche del buffer di uno \textit{stream}; queste
3397 vengono usate dalla funzione \func{setbuf}. Non è detto però che tale
3398 dimensione corrisponda sempre al valore ottimale (che può variare a seconda
3401 Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
3402 (come delle scritture accidentali sul buffer) e non assicura la scelta delle
3403 dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
3404 di libreria, che sono in grado di farlo in maniera ottimale e trasparente
3405 all'utente (in quanto la deallocazione avviene automaticamente). Inoltre
3406 siccome alcune implementazioni usano parte del buffer per mantenere delle
3407 informazioni di controllo, non è detto che le dimensioni dello stesso
3408 coincidano con quelle su cui viene effettuato l'I/O.
3413 \begin{tabular}[c]{|l|l|}
3415 \textbf{Valore} & \textbf{Modalità} \\
3418 \const{\_IONBF} & \textit{unbuffered}\\
3419 \const{\_IOLBF} & \textit{line buffered}\\
3420 \const{\_IOFBF} & \textit{fully buffered}\\
3423 \caption{Valori dell'argomento \param{mode} di \func{setvbuf}
3424 per l'impostazione delle modalità di bufferizzazione.}
3425 \label{tab:file_stream_buf_mode}
3428 Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
3429 \val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
3430 usando il buffer allocato automaticamente dal sistema. Si potrà comunque
3431 modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
3432 opportuni valori elencati in tab.~\ref{tab:file_stream_buf_mode}. Qualora si
3433 specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
3434 vengono sempre ignorati.
3436 Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
3437 gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
3438 \funcd{setbuffer} e \funcd{setlinebuf}; i loro prototipi sono:
3442 \funcdecl{void setbuf(FILE *stream, char *buf)} Disabilita la
3443 bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
3444 come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
3446 \funcdecl{void setbuffer(FILE *stream, char *buf, size\_t size)} Disabilita
3447 la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
3448 come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
3450 \funcdecl{void setlinebuf(FILE *stream)} Pone lo \textit{stream} in modalità
3451 \textit{line buffered}.
3453 \noindent tutte queste funzioni sono realizzate con opportune chiamate a
3454 \func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
3455 BSD. Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
3456 queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
3457 \funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
3458 di uno \textit{stream}; i cui prototipi sono:
3460 \headdecl{stdio\_ext.h}
3462 \funcdecl{int \_\_flbf(FILE *stream)} Restituisce un valore diverso da zero
3463 se \param{stream} è in modalità \textit{line buffered}.
3465 \funcdecl{size\_t \_\_fbufsize(FILE *stream)} Restituisce le dimensioni del
3466 buffer di \param{stream}.
3469 Come già accennato, indipendentemente dalla modalità di bufferizzazione
3470 scelta, si può forzare lo scarico dei dati sul file con la funzione
3471 \funcd{fflush}, il suo prototipo è:
3472 \begin{prototype}{stdio.h}{int fflush(FILE *stream)}
3474 Forza la scrittura di tutti i dati bufferizzati dello
3475 \textit{stream} \param{stream}.
3477 \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
3478 errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
3479 aperto o non è aperto in scrittura, o ad uno degli errori di
3482 \noindent anche di questa funzione esiste una analoga
3483 \func{fflush\_unlocked}\footnote{accessibile definendo \macro{\_BSD\_SOURCE} o
3484 \macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
3487 % TODO aggiungere prototipo \func{fflush\_unlocked}?
3489 Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
3490 \textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
3491 essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
3492 poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
3493 line buffered; per questo motivo le \acr{glibc} supportano una estensione di
3494 Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
3495 \begin{prototype}{stdio-ext.h}{void \_flushlbf(void)}
3496 Forza la scrittura di tutti i dati bufferizzati degli \textit{stream} in
3497 modalità line buffered.
3500 Si ricordi comunque che lo scarico dei dati dai buffer effettuato da queste
3501 funzioni non comporta la scrittura di questi su disco; se si vuole che il
3502 kernel dia effettivamente avvio alle operazioni di scrittura su disco occorre
3503 usare \func{sync} o \func{fsync} (si veda~sez.~\ref{sec:file_sync}).
3505 Infine esistono anche circostanze in cui si vuole scartare tutto l'output
3506 pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
3507 \begin{prototype}{stdio.h}{int fpurge(FILE *stream)}
3509 Cancella i buffer di input e di output dello \textit{stream} \param{stream}.
3511 \bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
3515 La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
3516 scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
3517 compresi gli eventuali caratteri rimandati indietro con \func{ungetc}.
3520 \subsection{Gli \textit{stream} e i \textit{thread}}
3521 \label{sec:file_stream_thread}
3525 Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
3526 allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
3527 essere consapevoli delle possibili complicazioni anche quando non si usano i
3528 \textit{thread}, dato che l'implementazione delle librerie è influenzata
3529 pesantemente dalle richieste necessarie per garantirne l'uso con i
3532 Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto
3533 ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
3534 funzioni di libreria durante la lettura e la scrittura di uno \textit{stream}
3535 devono essere opportunamente protette (in quanto il sistema assicura
3536 l'atomicità solo per le \textit{system call}). Questo viene fatto associando
3537 ad ogni \textit{stream} un opportuno blocco che deve essere implicitamente
3538 acquisito prima dell'esecuzione di qualunque operazione.
3540 Ci sono comunque situazioni in cui questo non basta, come quando un
3541 \textit{thread} necessita di compiere più di una operazione sullo
3542 \textit{stream} atomicamente, per questo motivo le librerie provvedono anche
3543 delle funzioni \funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile},
3544 che permettono la gestione esplicita dei blocchi sugli \textit{stream}; esse
3545 sono disponibili definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro
3550 \funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
3551 \textit{stream} \param{stream}, bloccandosi se il lock non è disponibile.
3553 \funcdecl{int ftrylockfile(FILE *stream)} Tenta l'acquisizione del lock
3554 dello \textit{stream} \param{stream}, senza bloccarsi se il lock non è
3555 disponibile. Ritorna zero in caso di acquisizione del lock, diverso da zero
3558 \funcdecl{void funlockfile(FILE *stream)} Rilascia il lock dello
3559 \textit{stream} \param{stream}.
3561 \noindent con queste funzioni diventa possibile acquisire un blocco ed
3562 eseguire tutte le operazioni volute, per poi rilasciarlo.
3564 Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
3565 blocco non sono del tutto indolori, e quando il locking dello \textit{stream}
3566 non è necessario (come in tutti i programmi che non usano i \textit{thread}),
3567 tutta la procedura può comportare dei costi pesanti in termini di
3568 prestazioni. Per questo motivo abbiamo visto come alle usuali funzioni di I/O
3569 non formattato siano associate delle versioni \code{\_unlocked} (alcune
3570 previste dallo stesso standard POSIX, altre aggiunte come estensioni dalle
3571 \acr{glibc}) che possono essere usate quando il locking non serve\footnote{in
3572 certi casi dette funzioni possono essere usate, visto che sono molto più
3573 efficienti, anche in caso di necessità di locking, una volta che questo sia
3574 stato acquisito manualmente.} con prestazioni molto più elevate, dato che
3575 spesso queste versioni (come accade per \func{getc} e \func{putc}) sono
3576 realizzate come macro.
3578 La sostituzione di tutte le funzioni di I/O con le relative versioni
3579 \code{\_unlocked} in un programma che non usa i \textit{thread} è però un
3580 lavoro abbastanza noioso; per questo motivo le \acr{glibc} forniscono al
3581 programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni
3582 introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
3583 locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
3585 \begin{prototype}{stdio\_ext.h}{int \_\_fsetlocking (FILE *stream, int type)}
3586 Specifica o richiede a seconda del valore di \param{type} la modalità in cui
3587 le operazioni di I/O su \param{stream} vengono effettuate rispetto
3588 all'acquisizione implicita del blocco sullo \textit{stream}.
3590 \bodydesc{Restituisce lo stato di locking interno dello \textit{stream} con
3591 uno dei valori \const{FSETLOCKING\_INTERNAL} o
3592 \const{FSETLOCKING\_BYCALLER}.}
3595 La funzione imposta o legge lo stato della modalità di operazione di uno
3596 \textit{stream} nei confronti del locking a seconda del valore specificato
3597 con \param{type}, che può essere uno dei seguenti:
3598 \begin{basedescript}{\desclabelwidth{4.0cm}}
3599 \item[\const{FSETLOCKING\_INTERNAL}] Lo \textit{stream} userà da ora in poi il
3600 blocco implicito predefinito.
3601 \item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
3602 dover gestire da solo il locking dello \textit{stream}.
3603 \item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
3604 di blocco dello \textit{stream}.
3607 % TODO trattare \func{clearerr\_unlocked}
3614 %%% Local Variables:
3616 %%% TeX-master: "gapil"
3619 % LocalWords: stream cap system call kernel Ritchie glibc descriptor Stevens
3620 % LocalWords: buf read write filesystem st blksize stat sez l'header stdio BSD
3621 % LocalWords: nell'header stdin shell stdout stderr error freopen flush line
3622 % LocalWords: unbuffered buffered newline fully SVr fopen fdopen POSIX const
3623 % LocalWords: char path int fildes NULL errno malloc fcntl fclose fflush tab
3624 % LocalWords: dup fifo socket append EXCL ccs IRUSR IWUSR IRGRP IWGRP
3625 % LocalWords: IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
3626 % LocalWords: sync fcloseall void stdlib of feof ferror clearerr ws
3627 % LocalWords: unlocked fread fwrite size ptr nmemb nelem gcc padding point str
3628 % LocalWords: lock thread fgetc getc getchar dell'overhead unsigned ap
3629 % LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar
3630 % LocalWords: SVID getw putw parsing peeking ahead ungetc gets fgets string Di
3631 % LocalWords: overflow Aleph stack fputs puts fgetws fputws getline ssize leak
3632 % LocalWords: realloc value result argument memory getdelim delim printf short
3633 % LocalWords: fprintf sprintf format snprintf variadic long double intmax list
3634 % LocalWords: uintmax ptrdiff vprintf vfprintf vsprintf vsnprintf asprintf lex
3635 % LocalWords: vasprintf strptr dprintf vdprintf print scanf fscanf sscanf flex
3636 % LocalWords: vscanf vfscanf vsscanf bison parser yacc like off VMS whence pos
3637 % LocalWords: lseek ftell fgetpos fpos fseeko ftello fileno Solaris freadable
3638 % LocalWords: fwritable ext freading fwriting buffering setvbuf BUFSIZ setbuf
3639 % LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
3640 % LocalWords: fsync fpurge flockfile ftrylockfile funlockfile
3641 % LocalWords: locking fsetlocking type Virtual operation
3642 % LocalWords: modification hole functions FSETSIG
3647 %%% Local Variables:
3649 %%% TeX-master: "gapil"