%% fileio.tex (merge fileunix.tex - filestd.tex)
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\chapter{La gestione dell'I/O su file}
\label{cha:file_IO_interface}
-Esamineremo in questo capitol le due interfacce di programmazione che
+Esamineremo in questo capitolo le due interfacce di programmazione che
consentono di gestire i dati mantenuti nei file. Cominceremo con quella nativa
del sistema, detta dei \textit{file descriptor}, che viene fornita
direttamente dalle \textit{system call} e che non prevede funzionalità evolute
analoga di quella delle voci di una directory, con la possibilità di avere più
voci che fanno riferimento allo stesso \textit{inode}. L'analogia è in realtà
molto stretta perché quando si cancella un file, il kernel verifica anche che
-non resti nessun riferimento in una una qualunque voce della \textit{file
- table} prima di liberare le risorse ad esso associate e disallocare il
-relativo \textit{inode}.
+non resti nessun riferimento in una qualunque voce della \textit{file table}
+prima di liberare le risorse ad esso associate e disallocare il relativo
+\textit{inode}.
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
\item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
\param{pathname} non è una directory.
\item[\errcode{ENXIO}] si sono impostati \const{O\_NONBLOCK} o
- \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
- processo o \param{pathname} è un file di dispositivo ma il dispositivo è
- assente.
+ \const{O\_WRONLY} ed il file è una \textit{fifo} che non viene letta da
+ nessun processo o \param{pathname} è un file di dispositivo ma il
+ dispositivo è assente.
\item[\errcode{EPERM}] si è specificato \const{O\_NOATIME} e non si è né
amministratori né proprietari del file.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
serve ad evitare dei possibili
\itindex{Denial~of~Service~(DoS)}
\textit{DoS}\footnotemark quando \func{opendir}
- viene chiamata su una fifo o su un dispositivo
+ viene chiamata su una \textit{fifo} o su un dispositivo
associato ad una unità a nastri. Non viene
usato al di fuori dell'implementazione di
\func{opendir}, ed è utilizzabile soltanto se si è
la macro \macro{\_GNU\_SOURCE}.\\
\constd{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
ne tronca la lunghezza a zero; con un terminale o
- una fifo viene ignorato, negli altri casi il
+ una \textit{fifo} viene ignorato, negli altri casi il
comportamento non è specificato.\\
\hline
\end{tabular}
tutte le volte che il file è pronto per le
operazioni di lettura o scrittura. Questo flag si
può usare solo terminali, pseudo-terminali e socket
- e, a partire dal kernel 2.6, anche sulle fifo. Per
+ e, a partire dal kernel 2.6, anche sulle \textit{fifo}. Per
un bug dell'implementazione non è opportuno usarlo
in fase di apertura del file, deve
invece essere attivato successivamente con
blocco delle stesse in attesa di una successiva
possibilità di esecuzione come avviene
normalmente. Questa modalità ha senso solo per le
- fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
+ \textit{fifo}, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
si vuole aprire un file di dispositivo per eseguire
una \func{ioctl} (vedi
sez.~\ref{sec:file_fcntl_ioctl}).\\
conseguente effetto sulle caratteristiche operative che controllano (torneremo
sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
-Il flag \const{O\_ASYNC} (che, per per compatibilità con BSD, si può indicare
+Il flag \const{O\_ASYNC} (che, per compatibilità con BSD, si può indicare
anche con la costante \constd{FASYNC}) è definito come possibile valore per
\func{open}, ma per un bug dell'implementazione,\footnote{segnalato come
ancora presente nella pagina di manuale almeno fino al Settembre 2011.} non
la dimensione di un file sarà più o meno corrispondente alla quantità di
spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
sposta in una posizione oltre la fine corrente del file, o come quello
-accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
-di un file con una \func{truncate}, in cui in sostanza si modifica il valore
+accennato in sez.~\ref{sec:file_file_size} in cui si estende la dimensione di
+un file con una \func{truncate}, in cui in sostanza si modifica il valore
della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
consente di creare inizialmente file di dimensioni anche molto grandi, senza
dover occupare da subito dello spazio disco che in realtà sarebbe
La funzione \func{read} è una delle \textit{system call} fondamentali,
esistenti fin dagli albori di Unix, ma nella seconda versione delle
\textit{Single Unix Specification}\footnote{questa funzione, e l'analoga
- \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nelle
+ \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nella
\acr{glibc}, compresa l'emulazione per i vecchi kernel che non hanno la
\textit{system call}, è stato aggiunto con la versione 2.1, in versioni
precedenti sia del kernel che delle librerie la funzione non è disponibile.}
figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
una copia di \kstruct{file\_struct} e della relativa tabella dei file aperti.
-Questo significa che il figlio avrà gli stessi file aperti del padre, in
+Questo significa che il figlio avrà gli stessi file aperti del padre in
quanto la sua \kstruct{file\_struct}, pur essendo allocata in maniera
indipendente, contiene gli stessi valori di quella del padre e quindi i suoi
file descriptor faranno riferimento alla stessa voce nella \textit{file
file vi si vuole far corrispondere, invece di duplicare un file descriptor che
si è già aperto. La risposta sta nel fatto che il file che si vuole redirigere
non è detto sia un file regolare, ma potrebbe essere, come accennato, anche
-una fifo o un socket, oppure potrebbe essere un file associato ad un file
+una \textit{fifo} o un socket, oppure potrebbe essere un file associato ad un file
descriptor che si è ereditato già aperto (ad esempio attraverso un'altra
\func{exec}) da un processo antenato del padre, del quale non si conosce il
nome. Operando direttamente con i file descriptor \func{dup} consente di
anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
+
+
+% TODO trattare fstatat e con essa
+% TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
+% https://lwn.net/Articles/707602/ e
+% https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f)
+
% TODO manca prototipo di linkat, verificare se metterlo o metter menzione
% altre modifiche al riguardo nel 3.11 (AT_EMPTY_PATH?) vedi
% http://lwn.net/Articles/562488/
\end{table}
+\texttt{ATTENZIONE PARTE DA RIVEDERE}
+
+
Un'ultima differenza fra le \textit{at-functions} e le funzioni tradizionali
di cui sono estensione è, come accennato in sez.~\ref{sec:file_temp_file},
-quella relativa a \funcm{utimensat} che non è propriamente una corrispondente
+quella relativa a \func{utimensat} che non è propriamente una corrispondente
esatta di \func{utimes} e \func{lutimes}, dato che questa funzione ha una
maggiore precisione nella indicazione dei tempi dei file, per i quali come per
\func{futimes}, si devono usare strutture \struct{timespec} che consentono una
-precisione fino al nanosecondo.
+precisione fino al nanosecondo; la funzione è stata introdotta con il kernel
+2.6.22,\footnote{in precedenza, a partire dal kernel 2.6.16, era stata
+ introdotta una \textit{system call} \funcm{futimesat} seguendo una bozza
+ della revisione dello standard poi modificata; questa funzione, sostituita
+ da \func{utimensat}, è stata dichiarata obsoleta, non è supportata da
+ nessuno standard e non deve essere più utilizzata: pertanto non ne
+ parleremo.} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int utimensat(int dirfd, const char *pathname, const struct
+ timespec times[2], int flags)}
+\fdesc{Cambia i tempi di un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] si è richiesta l'impostazione del tempo corrente ma
+ non si ha il permesso di scrittura sul file, o non si è proprietari del
+ file o non si hanno i privilegi di amministratore; oppure il file è
+ immutabile (vedi sez.~\ref{sec:file_perm_overview}).
+ \item[\errcode{EBADF}] \param{dirfd} non è \const{AT\_FDCWD} o un file
+ descriptor valido.
+ \item[\errcode{EFAULT}] \param{times} non è un puntatore valido oppure
+ \param{dirfd} è \const{AT\_FDCWD} ma \param{pathname} è \var{NULL} o non è
+ un puntatore valido.
+ \item[\errcode{EINVAL}] si sono usati dei valori non corretti per i tempi di
+ \param{times}, oppure è si usato un valore non valido per \param{flags},
+ oppure \param{pathname} è \var{NULL}, \param{dirfd} non è
+ \const{AT\_FDCWD} e \param{flags} contiene \const{AT\_SYMLINK\_NOFOLLOW}.
+ \item[\errcode{EPERM}] si è richiesto un cambiamento nei tempi non al tempo
+ corrente, ma non si è proprietari del file o non si hanno i privilegi di
+ amministratore; oppure il file è immutabile o \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}).
+ \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
+ componenti di \param{pathname}.
+ \end{errlist}
+ ed inoltre per entrambe \errval{EROFS} e per \func{utimensat}
+ \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel
+ loro significato generico.}
+\end{funcproto}
+
+La funzione imposta i tempi dei file utilizzando i valori passati nel vettore
+di strutture \struct{timespec} esattamente come \func{futimes} (si veda quanto
+illustrato in sez.~\ref{sec:file_file_times}).
+
+La funzione supporta invece, rispetto ad \func{utimes} che abbiamo visto in
+sez.~\ref{sec:file_file_times}, una sintassi più complessa che consente una
+indicazione sicura del file su cui operare specificando la directory su cui si
+trova tramite il file descriptor \param{dirfd} ed il suo nome come
+\textit{pathname relativo} in \param{pathname}.\footnote{su Linux solo
+ \func{utimensat} è una \textit{system call} e \func{futimens} è una funzione
+ di libreria, infatti se \param{pathname} è \var{NULL} \param{dirfd} viene
+ considerato un file descriptor ordinario e il cambiamento del tempo
+ applicato al file sottostante, qualunque esso sia, per cui
+ \code{futimens(fd, times}) è del tutto equivalente a \code{utimensat(fd,
+ NULL, times, 0)} ma nella \acr{glibc} questo comportamento è disabilitato
+ seguendo lo standard POSIX, e la funzione ritorna un errore di
+ \errval{EINVAL} se invocata in questo modo.}
+
+Torneremo su questa sintassi e sulla sua motivazione in
+sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
+cosiddette \textit{at-functions}) che la utilizzano; essa prevede comunque
+anche la presenza dell'argomento \param{flags} con cui attivare flag di
+controllo che modificano il comportamento della funzione, nel caso specifico
+l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
+funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
+di riprodurre le funzionalità di \func{lutimes}.
+
+
+\texttt{ATTENZIONE PARTE DA RIVEDERE}
-% NOTA: manca prototipo di utimensat, per ora si lascia una menzione
\itindend{at-functions}
modifica è opportuno rileggere la nuova dimensione con
\const{F\_GETPIPE\_SZ}. I processi non privilegiati\footnote{per la
precisione occorre la capacità \const{CAP\_SYS\_RESOURCE}.} non possono
- impostare un valore valore superiore a quello indicato da
+ impostare un valore superiore a quello indicato da
\sysctlfiled{fs/pipe-size-max}. Il comando è specifico di Linux, è
disponibile solo a partire dal kernel 2.6.35, ed è utilizzabile solo se si è
definita la macro \macro{\_GNU\_SOURCE}.
\end{basedescript}
+% TODO: trattare RWH_WRITE_LIFE_EXTREME e RWH_WRITE_LIFE_SHORT aggiunte con
+% il kernel 4.13 (vedi https://lwn.net/Articles/727385/)
+
La maggior parte delle funzionalità controllate dai comandi di \func{fcntl}
sono avanzate e richiedono degli approfondimenti ulteriori, saranno pertanto
riprese più avanti quando affronteremo le problematiche ad esse relative. In
di questa funzione con i socket verrà trattato in
sez.~\ref{sec:sock_ctrl_func}.
-La gran parte dei comandi di \func{fcntl} (\const{F\_DUPFD}, \const{F\_GETFD},
-\const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL}, \const{F\_GETLK},
-\const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4 e 4.3BSD e
-standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
+La gran parte dei comandi di \func{fcntl} (come \const{F\_DUPFD},
+\const{F\_GETFD}, \const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL},
+\const{F\_GETLK}, \const{F\_SETLK} e \const{F\_SETLKW}) sono previsti da SVr4
+e 4.3BSD e standardizzati in POSIX.1-2001 che inoltre prevede gli ulteriori
\const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si sono indicate
esplicitamente soltanto le ulteriori richieste in termini delle macro di
funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
% TODO trovare qualche posto per la eventuale documentazione delle seguenti
% (bassa/bassissima priorità)
% EXT4_IOC_MOVE_EXT (dal 2.6.31)
+% EXT4_IOC_SHUTDOWN (dal 4.10), XFS_IOC_GOINGDOWN e futura FS_IOC_SHUTDOWN
% ioctl di btrfs, vedi http://lwn.net/Articles/580732/
% \chapter{}
Queste funzioni di libreria, insieme alle altre funzioni definite dallo
standard (che sono state implementate la prima volta da Ritchie nel 1976 e da
allora sono rimaste sostanzialmente immutate), vengono a costituire il nucleo
-delle \acr{glibc} per la gestione dei file.
+della \acr{glibc} per la gestione dei file.
Esamineremo in questa sezione le funzioni base dell'interfaccia degli
\textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
\func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
-usare gli \textit{stream} con file come le fifo o i socket, che non possono
+usare gli \textit{stream} con file come le \textit{fifo} o i socket, che non possono
essere aperti con le funzioni delle librerie standard del C.
\begin{table}[htb]
distinzione non esiste e il valore viene accettato solo per
compatibilità, ma non ha alcun effetto.
-Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
+La \acr{glibc} supporta alcune estensioni, queste devono essere sempre
indicate dopo aver specificato il \param{mode} con uno dei valori di
tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
evitare di sovrascrivere un file già esistente (è analoga all'uso dell'opzione
tutti i dati presenti nei buffer di uscita e scarta tutti i dati in ingresso;
se era stato allocato un buffer per lo \textit{stream} questo verrà
rilasciato. La funzione effettua lo scarico solo per i dati presenti nei
-buffer in \textit{user space} usati dalle \acr{glibc}; se si vuole essere
+buffer in \textit{user space} usati dalla \acr{glibc}; se si vuole essere
sicuri che il kernel forzi la scrittura su disco occorrerà effettuare una
\func{sync} (vedi sez.~\ref{sec:file_sync}).
-Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
-GNU implementata dalle \acr{glibc}, accessibile avendo definito
+Linux supporta anche un'altra funzione, \funcd{fcloseall}, come estensione
+GNU implementata dalla \acr{glibc}, accessibile avendo definito
\macro{\_GNU\_SOURCE}, il suo prototipo è:
\begin{funcproto}{
Una delle caratteristiche più utili dell'interfaccia degli \textit{stream} è
la ricchezza delle funzioni disponibili per le operazioni di lettura e
-scrittura sui file. Sono infatti previste ben tre diverse modalità modalità di
+scrittura sui file. Sono infatti previste ben tre diverse modalità di
input/output non formattato:
\begin{itemize}
\item\textsl{binario} in cui si leggono e scrivono blocchi di dati di
funzioni. Nella maggior parte dei casi questo avviene con la restituzione del
valore intero (di tipo \ctyp{int}) \val{EOF} definito anch'esso nell'header
\headfile{stdlib.h}. La costante deve essere negativa perché in molte funzioni
-un valore positivo indica la quantità di dati scritti, le \acr{glibc} usano il
+un valore positivo indica la quantità di dati scritti, la \acr{glibc} usa il
valore $-1$, ma altre implementazioni possono avere valori diversi.
Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
-sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo
-(ad esempio i terminali), non è scontato che questo sia vero in generale, pur
-essendolo sempre nel caso di file di dati.
+sistema Unix esistono vari tipi di file, come le \textit{fifo} ed i file di
+dispositivo (ad esempio i terminali), non è scontato che questo sia vero in
+generale, pur essendolo sempre nel caso di file di dati.
Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero
ordinamento dei bit o il formato delle variabili in floating point.
Per questo motivo quando si usa l'input/output binario occorre sempre prendere
-le opportune precauzioni (in genere usare un formato di più alto livello che
-permetta di recuperare l'informazione completa), per assicurarsi che versioni
-diverse del programma siano in grado di rileggere i dati tenendo conto delle
+le opportune precauzioni come usare un formato di più alto livello che
+permetta di recuperare l'informazione completa, per assicurarsi che versioni
+diverse del programma siano in grado di rileggere i dati, tenendo conto delle
eventuali differenze.
-Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
-\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
-implicito dello \textit{stream}, usato per dalla librerie per la gestione
-delle applicazioni \textit{multi-thread} (si veda
-sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
+La \acr{glibc} definisce infine due ulteriori funzioni per l'I/O binario,
+\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked}, che evitano il lock
+implicito dello \textit{stream} usato per dalla librerie per la gestione delle
+applicazioni \textit{multi-thread} (si veda sez.~\ref{sec:file_stream_thread}
+per i dettagli), i loro prototipi sono:
\begin{funcproto}{
\fhead{stdio.h}
ritorno è sempre un intero; in caso di errore o fine del file il valore di
ritorno è \val{EOF}.
-Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
-provvedono come estensione, per ciascuna delle funzioni precedenti,
+Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} la \acr{glibc}
+provvede come estensione, per ciascuna delle funzioni precedenti,
un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
il lock implicito dello \textit{stream}.
caratteri massimo, terminatore della stringa, \textit{newline}) è espresso in
termini di caratteri estesi anziché di normali caratteri ASCII.
-Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
-\acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
+Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea la
+\acr{glibc} supporta una serie di altre funzioni, estensioni di tutte quelle
illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
complicazione ulteriore della logica del programma. Lo stesso dicasi quando si
deve gestire il caso di stringa che eccede le dimensioni del buffer.
-Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
+Per questo motivo la \acr{glibc} prevede, come estensione GNU, due nuove
funzioni per la gestione dell'input/output di linea, il cui uso permette di
risolvere questi problemi. L'uso di queste funzioni deve essere attivato
definendo la macro \macro{\_GNU\_SOURCE} prima di includere
Dettagli ulteriori sulle varie opzioni di stampa e su tutte le casistiche
dettagliate dei vari formati possono essere trovati nella pagina di manuale di
-\func{printf} e nella documentazione delle \acr{glibc}.
+\func{printf} e nella documentazione della \acr{glibc}.
\begin{table}[htb]
\centering
\textit{stream}. Altre estensioni permettono di scrivere con caratteri
estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
-dettaglio nella documentazione delle \acr{glibc}.
+dettaglio nella documentazione della \acr{glibc}.
In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
l'output formattato, l'input formattato viene eseguito con le funzioni della
qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
-si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
+si trovano descritte in dettaglio nelle pagine di manuale e nel manuale della
\acr{glibc}.
Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
In questo modo diventa possibile usare direttamente \func{fcntl} sul file
descriptor sottostante, ma anche se questo permette di accedere agli attributi
del file descriptor sottostante lo \textit{stream}, non ci dà nessuna
-informazione riguardo alle proprietà dello \textit{stream} medesimo. Le
-\acr{glibc} però supportano alcune estensioni derivate da Solaris, che
+informazione riguardo alle proprietà dello \textit{stream} medesimo. La
+\acr{glibc} però supporta alcune estensioni derivate da Solaris, che
permettono di ottenere informazioni utili relative allo \textit{stream}.
Ad esempio in certi casi può essere necessario sapere se un certo
specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
vengono sempre ignorati.
-Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
+Oltre a \func{setvbuf} la \acr{glibc} definisce altre tre funzioni per la
gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
\funcd{setbuffer} e \funcd{setlinebuf}, i rispettivi prototipi sono:
vecchie librerie BSD, pertanto non è il caso di usarle se non per la
portabilità su vecchi sistemi.
-Infine le \acr{glibc} provvedono le funzioni non standard, anche queste
+Infine la \acr{glibc} provvede le funzioni non standard, anche queste
originarie di Solaris, \funcd{\_\_flbf} e \funcd{\_\_fbufsize} che permettono
di leggere le proprietà di bufferizzazione di uno \textit{stream}; i cui
prototipi sono:
\end{funcproto}
\noindent anche di questa funzione esiste una analoga \func{fflush\_unlocked}
-(accessibile definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} o
+(accessibile definendo una fra \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE} o
\macro{\_GNU\_SOURCE}) che non effettua il blocco dello \textit{stream}.
% TODO aggiungere prototipo \func{fflush\_unlocked}?
\textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
-\textit{line buffered}. Per fare questo le \acr{glibc} supportano una
+\textit{line buffered}. Per fare questo la \acr{glibc} supporta una
estensione di Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
\begin{funcproto}{
\subsection{Gli \textit{stream} e i \textit{thread}}
\label{sec:file_stream_thread}
-\itindbeg{thread}
Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
Per questo motivo abbiamo visto come alle usuali funzioni di I/O non
formattato siano associate delle versioni \code{\_unlocked} (alcune previste
-dallo stesso standard POSIX, altre aggiunte come estensioni dalle \acr{glibc})
+dallo stesso standard POSIX, altre aggiunte come estensioni dalla \acr{glibc})
che possono essere usate quando il locking non serve\footnote{in certi casi
dette funzioni possono essere usate, visto che sono molto più efficienti,
anche in caso di necessità di locking, una volta che questo sia stato
La sostituzione di tutte le funzioni di I/O con le relative versioni
\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
-lavoro abbastanza noioso. Per questo motivo le \acr{glibc} forniscono al
+lavoro abbastanza noioso. Per questo motivo la \acr{glibc} fornisce al
programmatore pigro un'altra via, anche questa mutuata da estensioni
introdotte in Solaris, da poter utilizzare per disabilitare in blocco il
locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
% TODO trattare \func{clearerr\_unlocked}
-\itindend{thread}
-
%%% Local Variables:
% LocalWords: FIONREAD epoll FIOQSIZE side effects SAFE BYCALLER QUERY EACCES
% LocalWords: EBUSY OpenBSD syncfs futimes timespec only init ESRCH kill NTPL
% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK PGRP SZ
-% LocalWords: EFAULT capabilities GETPIPE SETPIPE RESOURCE
+% LocalWords: EFAULT capabilities GETPIPE SETPIPE RESOURCE dell'I all' NFSv
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: l'I nell' du vm Documentation Urlich Drepper futimesat times
+% LocalWords: futimens fs Tread all'I ll